11｜SQL优化：如何发现SQL中的问题？

这里列一下我个人之前总结的SQL优化的思路（稍微增加了一些本章节提到了，但是我也学习到了的内容）： 1. 索引的角度。 （1）根据执行计划优化索引，从type，keys，extra这几个主要字段去分析。 （2）避免返回不需要的列（覆盖索引，避免回表） 2. 架构层面。 （1）分库分表 （2）读写分离 （3）为了避免like这种，以及超级大数据量查询（没办法避免多表查询），可以借助数仓，建宽表，以及引入es等方法进行实现。 3. 分析问题角度 （1）执行sql之前，先执行“set profiling = 1;”，然后执行完查询sql之后，执行"show profiles "可以展示详细的具体执行时间。 （2）show profiles的方法已经开始被MySQL逐渐淘汰，后续会被 performance_schema代替，performance_schema是一个数据库，里面有87张表，可以通过查询这些表来查看执行情况。 4. 常见技巧 （1）深度分页问题：limit m,n分页越往后越慢的问题。 a. select * from tableA where id >=(select id from tableA limit m, 1) limit n； 这种做法有个弊端，要求主键必须自增。 b. select * from tableA a inner join (select id from tableA limit m, n)b on a.id = b.id (2)避免For循环里面查单条数据，改为一条sql查集合。 (3)建表的时候考虑增加冗余字段，尽可能保持单表查询，而非多表Join. (4)在所有的排序场景中，都应该尽量利用索引来排序. (5)算count行数的时候，如果业务场景要求不高，可以有一个偏门方法，就是执行explain select * from t where xxxx，在执行计划里面会预估出来大致的行数。 (6)where 替代 having

1. 按前台业务和后台业务分表，前台业务表不包含各种审核状态，只包含纯粹的业务数据，所以表数据更少，字段更小，每次读到buffer pool 中能读更多的数据，性能更好 2. 避免like查询，搜索功能使用专业的搜索引擎，而且还能更加为业务提供更多发展空间，比如es的分词，权重打分等 3. 避免循环中查询单条数据的错误，写的时候要思考如果该接口高并发时会不会挂 4. 适当冗余少量字段，做一定的反范式设计，尽量使用单表查询 5. 索引是有代价的，在上千万的数据中，有时候索引占的空间比表数据更大，一定要避免滥用，不要为了sql建索引，而是从业务角度考虑索引

[WHERE id > max_id ] 具体实操过程中，max_id是如何获取的呢？假如直接点击第1000页的内容，是不是就没法实现了？

SQL查询分页偏移量大的问题，又名深度分页。

老师你好，如果一个表单管理，有很多的筛选条件，超过10个，需要怎么设置索引比较合理，好像也避免不了回表的问题

"SHOW TABLE STATUS 也能看到一个 TABLE_ROWS 列，代表表的行数，那么能不能用这个来优化 COUNT(*)？" 不太行，索引统计的值是通过采样来估算的。实际上，TABLE_ROWS 就是从这个采样估算得来的，因此它也很不准。有多不准呢，官方文档说误差可能达到 40% 到 50%。 《MySQL实战45讲》的第14章，也有介绍这一点

"优化 COUNT"这里"考虑使用 Redis 之类的 NoSQL 来直接记录总数"，这里不太好记录吧，像MySQL有一致性视图就很难模拟吧，市场有啥成熟的案例咩

修改索引或者说表定义变更的核心问题是数据库会加表锁，直到修改完成。 好像mysql是支持online ddl的吧。那如果支持的话，是不是对大表也可以直接ddl了

在之前的团队中用过强制force指定索引，之所以这样做是为了在mysql表的数据量特别大的时候，mysql自己的内部优化器会给推荐别的索引，现实中发现强制有另一个索引，查询的性能会很大，也就是可以理解为mysql自己的查询优化器有时候会选择错误的索引

1）请教一下老师，select count(distinct(name)) from user 这条sql如何优化，能用group by优化吗？select name from user group by name;