标签：JOIN 性能 使用 消耗 查询 索引 SQL 优化
SQL Server 查询优化器筛选条件分析
通过筛选条件减少扫描范围
注意项：
- 模糊查询，尽量不要把百分号放置在前面： LIKE‘%xx’，查询优化器无法对此优化，只能扫描查找（表扫描或索引扫描查找）
- 尽量避免使用OR（可考虑UNION ALL），扰乱查询优化器流程
- 避免对列值进行运算，查询不走索引
- 避免使用 NOT IN,全表扫描
优化慢查询SQL
避免使用SELECT *
查询不需要的字段，消耗数据库资源，甚至内存或CPU资源；返回数据通过网络IO传输过程中，增加数据传输时间；SELECT * 不会走索引会出现大量等待回表操作；
建议：只查询需要的数据列
尽量使用UNION ALL 代替 UNION
使用UNION会过滤重复数据，UNION ALL获取所有数据包含重复数据；排除重复的过程需要遍历、排序和比较，更耗时，更消耗CPU资源
小表驱动大表
子查询in / exist
使用in关键字，它会优先执行in里面的子查询，再执行外面的语句，如果子查询的数据量很少，数据会很快
使用exist关键字，则会优先执行主查询语句（exist左边的语句），然后把它作为条件，去跟右边的语句进行匹配
总结：in适用于左边大表，右边小表；exist适用于左边小表，右边大表
批量操作
每次请求数据库是会消耗一定性能的；批量操作减少性能消耗；
建议：批量操作数据量不要过多，数据量多执行的也慢；建议500ms,数据量多可分多批次处理
高效分页查询
查询结果集过多，查询慢、响应慢，网络传输消耗性能，传输慢（拥堵）、还可能造成接口超时
避免IN中的值过多
用连接查询代替子查询
子查询要创建临时表，查询完成后要删除这些临时表，有一些额外的性能消耗
JOIN的表不宜过多
JOIN的表过多，数据库在选择索引的时候会非常复杂，很容易选错索引；如果没有命中，nested loop join 会分别从两个表读一行数据进行两两对比
建议:JOIN的表不宜超过3个
LEFT JOIN/INNER JOIN
使用INNER JOIN 数据库会自动选择两张表中的小表去驱动大表，性能上不会有太大问题
使用LEFT JOIN,数据库会默认使用LEFT JOIN左边驱动右表
控制索引数量
索引能够显著提升查询SQL的性能，但索引数量并非越多越好；因为表中新增数据时，需要同时为它创建索引，而索引需要额外的存储空间，有一定的性能消耗
建议：单表索引数量尽量控制在5个以内，并且单个索引的字段数不超过5个；数据库使用B+树的结构来保存索引的，在insert\updae\delete需要更新索引，如果索引过多，会消耗很多额外的性能；
能用联合索引就别用单个索引，可删除无用的单个索引
选择合理的字段类型
char 该类型的字段存储空间是固定，存储内容若不是固定的，会浪费存储空间
varchar 表示变长字符串类型，该类型的字段存储空间会根据实际数据的长度调整，不会浪费存储空间
对于查询，在一个相对较小的字段内搜索效率显然要高些
建议：选择字段类型时，能用数字类型，就不用字符串，因为字符串的处理往往比数字要慢，尽可能用小的类型
提升GROUP BY效率
group by 会与having结合使用，分组会消耗性能，要在分组前用where把数据过滤掉在分组，减少性能消耗
索引优化
索引失效常见原因
- 不满足最左前缀原则
- 范围索引列没有放最后
- 使用了select *
- 索引列上有计算
- 索引列上使用了函数
- 类型转换，字符串类型没加引号
- 使用 is null 和is not null 没注意字段是否允许为空
- like 查询左边有%
分页查询、分批调用接口、
标签：JOIN,
性能,
使用,
消耗,
查询,
索引,
SQL,
优化
From： https://www.cnblogs.com/xjxue/p/17644756.html