mysql分页问题引发的思考

mysql中分页查询慢引发的联想

mysql存储引擎分innodb、myisam

innodb支持事务、myisam不支持事务
innodb count(*)会扫描全表 myisam会把所有行数保存在磁盘中

使用最多innodb存储引擎

count(*) ：它会获取所有行的数据，不做任何处理，行数加1。
count(1)：它会获取所有行的数据，每行固定值1，也是行数加1。
count(id)：id代表主键，它需要从所有行的数据中解析出id字段，其中id肯定都不为NULL，行数加1。
count(普通索引列)：它需要从所有行的数据中解析出普通索引列，然后判断是否为NULL，如果不是NULL，则行数+1。
count(未加索引列)：它会全表扫描获取所有数据，解析中未加索引列，然后判断是否为NULL，如果不是NULL，则行数+1。
由此，最后count的性能从高到低是：
count(*) ≈ count(1) > count(id) > count(普通索引列) > count(未加索引列)

分页查询是一般 会有两条语句 select count(*) from table_name; select fields... from table_name limit 1,5;

多线程
一个查总条数，一个查分页数据

异步处理
一个请求查分页数据；一个请求查总条数（有结果后返回展示，数据量特别大的时候可能会有超时）

借助redis缓存：md5(查询条件) = count（*）条数 。存在数据一致性问题。适用于更改少、新增少、数据变动少。或者浏览量，点赞量可容仍短时间内不一致情况的数据。

减少表关联

读写分离，减少主库压力

以上治标不治本。

换产品、或增加产品
clickhouse（不支持事务）查询性能非常高，号称查询十几亿的数据，能够秒级返回。

为了避免对业务代码的嵌入性，可以使用Canal监听Mysql的binlog日志。当product表有数据新增时，需要同时查询出单位、品牌和分类的数据，生成一个新的结果集，保存到ClickHouse当中。
查询数据时，从ClickHouse当中查询，这样使用count(*)的查询效率能够提升N倍。

ElasticSearch，不过它跟Mysql一样，存在深分页问题。三种方式