sql优化常见问题

SQL优化方案：

SQL优化：

• 查询语句中不要使用*； 避免全表查询
• 尽量减少子查询，使用关联查询（left join, right join, inner join）代替；子查询会生成临时表导致索引失效
• 减少使用IN或者NOT IN，使用exists、not exists或者关联查询语句代替；
• 对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差；
• 合理的增加冗余的字段（减少表的关联查询）；
• 增加中间表进行优化（这个主要是在统计报表的场景，后台开定时任务将数据先统计好，尽量不要在查询的时候去统计）；
• 建表的时候能使用数字类型的字段就使用数字类型（type,status…），数字类型的字段作为条件查询比字符串快。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了；
• 那些可以过滤掉最大数量记录的条件必须写在where字句的最末尾；
• 索引并不是越多越好，索引固然可以提高相应的 select的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update时有可能会重建索引。一个表的索引数最好不要超过6个，应考虑一些不常使用到的列上建的索引是否有必要；
• 尽可能的使用 varchar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些；
• 对查询进行优化，应尽量避免全表扫描，首先应考虑在where以及order by涉及的列上建立索引。

索引失效情况优化：

• 应尽量避免在 where 字句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描；
• 应尽量避免在 where 字句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描；
• 应尽量避免在 where 字句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描；
• 应尽量避免在 where 字句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描；
• 最佳左前缀法则（带头索引不能死，中间索引不能断）：在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致；
• 使用like关键字模糊查询时，% 放在前面索引不起作用，只有“%”不在第一个位置，索引才会生效（like ‘%文’–索引不起作用）；
• 应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，尽量用union或者union all代替(在确认没有重复数据或者不用剔除重复数据时，union all会更好)；
• 如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则索引将会失效。
• 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描。
• 存储引擎不能使用索引中范围条件右边的列 ——范围之后索引失效。（< ,> between and,）
• 尽量使用覆盖索引（只访问索引的查询（索引和查询列一致）），减少select*。——按需取数据用多少取多少。

索引类型的性能排行：

System > const > eq_ref > ref > range > index > ALL
通常将type优化成ref就很好了

索引失效情况，强制走索引：

在sql的表名后使用force index (索引名)

回表问题：

原因是通过一个普通索引(columnA)查询方式，则需要先搜索(columnA)的索引树，然后得到主键 ID 的值为 1，再到主键索引树搜索一次。这个过程虽然用了索引，但实际上底层进行了两次索引查询，这个过程就称为回表。
也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。