表过大

历史数据进行归档

深度分页

合理 建表 ，避免大表的产生
冷热数据分离
分库分表
避免跳转，比如 跳到第1000页，引发深度分页
限制最大分页数
数据更新不频繁，可以放入缓存！！！

count(*) 与 count(列名)

count(*) 不会忽略null

count(列名) 会忽略null

唯一索引

创建唯一索引的字段，不能为NULL 否则唯一索引失效

逻辑删除的表，不方便建唯一索引

逻辑删除表加个字段：deleteID 默认值为1
逻辑删除时，给deleteID设为当前的主键ID

把 name，model，deleteStatus，deleteID四个字段同时做成唯一索引

任何一个字段数值不同代表不是相同的数据, 可以保证数据唯一性

分库分表

只分库不分表

当数据库的读或者写的QPS过高，导致数据库连接不足，考虑分库，增加数据库实例的方式，提供更多的数据库连接提升系统并发度

不分库只分表

当单表数据量非常大，因为并发不高，数据库的连接可能还够，但存储和查询性能遇到瓶颈，考虑水平分表，将数据拆分到多张表中，减少单表的数据量

分库也分表

数据库的读或者写的QPS过高，导致数据库连接不足
单表数据量非常大

查询分离

使用方法

写请求使用主库，mysql等关系型数据库

读请求查询读库，采用nosql 如：es、mongodb、hbase

写读数据库的同步，采用binlog订阅

查询分离的适用场景

当在业务中遇到一下情形，考虑使用查询分离

数据量大
写请求效率ok
读请求效率低
所有数据任何时候可能被修改
希望优化查询数据的性能

冷热分离

适用场景

主业务响应延迟太大
数据走到终态，没有更新的需求。只有读的需求，比如订单的完成状态
接受 新旧数据分开，比如携程的订单查询30天之前需要使用手机号

两个概念：

冷数据：不允许更新，偶尔查询，响应时间无要求
热数据：被频繁更新，响应时间有要求

实现方案

在这里插入图片描述

数据库连接池优化

连接数 = ((核心数 * 2) + 有效磁盘数)

主键无序

导致页分裂，会去重新挪数据，影响性能

分布式id，每秒一个机器大概4000个id，跟时间线性相关的，如果时钟回拨会导致无序
高并发情况下可以先批量生成，再使用，根据业务情况估计

比如每秒100万的id，内存挂掉，将id持久化，或者扔掉重新生成~影响也不大redis的自增id

buffer pool 太小

可以通过下面的命令查询到 buffer pool 的大小，单位是 Byte。

mysql> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.01 sec)

mysql> set global innodb_buffer_pool_size = 536870912;
Query OK, 0 rows affected (0.01 sec)
mysql> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 536870912 |
+-------------------------+-----------+
1 row in set (0.01 sec)

怎么知道 buffer pool 是不是太小了？

这个我们可以看 buffer pool 的缓存命中率
在这里插入图片描述
查看 buffer pool 命中率

show status like 'Innodb_buffer_pool_%';

可以看到跟 buffer pool 有关的一些信息。
Innodb_buffer_pool_read_requests 表示读请求的次数。
Innodb_buffer_pool_reads 表示从物理磁盘中读取数据的请求次数。
所以 buffer pool 的命中率就可以这样得到：