how to optimize sql
无法使用index 情况
- 使用负向条件查询，导致索引失效
- 使用模糊查询，前导模糊查询不能是索引生效，而后置模糊查询可以
- 数据区分度不大的字段 不宜使用索引
- 运算式中的字段无法使用其上的索引，或者说在属性上进行计算无法命中其索引
- 存在null值的列，如果建立索引，查询会存在隐患
- 复合索引最左前缀原则
- 把计算放到业务层而不是数据库层，除了节省数据的CPU，还有意想不到的查询缓存优化效果
- 条件中用or(新版本应该行)，即使其中有条件带索引，也不会使用索引查询
- 如果列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不会使用索引
- 强制类型转换会全表扫描
- 如果MySQL预计使用全表扫描要比使用索引快，则不使用索引
- 在索引上做任何操作都会造成索引失效，而使用全局扫描
- 对索引列运算，运算包括（+、-、*、/、！、<>、%、like’%_’（%放在前面）、or、in、exist等），导致索引失效。
- mysql使用!= ,<> ,is null ,is not null会使索引失效
- union all 肯定是能够命中索引的
- 如果业务大部分是单条查询，使用Hash索引性能更好，例如用户中心
- 如果明确知道只有一条结果返回，limit 1能够提高效率
- 加索引，左连接，加右表上，反之
- Exists
- select …from table wherer exists（subquery 子查询)
- 将主查询的数据，放到子查询中做条件验证，根据验证结果(True or False) 来决定主查询的数据结果是否得以保留
- exists子查询往往也可以用条件表达式，其他子查询或者join来替代，何种最优需要具体问题具体分析。
- exists只返回True or False ,因此子查询中select * 也可以是select 1 or select ‘x’ 官方说法是实际执行时会忽略select清单，因此没有区别
史上最全SQL优化方案
SQL语法，行为军规
- https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960284&idx=1&sn=d427372dd71b7f598f9ddc99b58f8b35&chksm=bd2d06008a5a8f164503bf2d10ea4d6ad482e496195436ff2573cd4440b3f44654820f353651&scene=27#wechat_redirect
- https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959906&idx=1&sn=2cbdc66cfb5b53cf4327a1e0d18d9b4a&chksm=bd2d07be8a5a8ea86dc3c04eced3f411ee5ec207f73d317245e1fefea1628feb037ad71531bc&scene=21#wechat_redirect
- https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959910&idx=1&sn=6b6853b70dbbe6d689a12a4a60b84d8b&chksm=bd2d07ba8a5a8eac6783bac951dba345d865d875538755fe665a5daaf142efe670e2c02b7c71&scene=21#wechat_redirect
事实表，实体表，维度表之间的关系
explain 用法详解
聚集索引与非聚集索引
- https://www.cnblogs.com/aspnethot/articles/1504082.html
- 对于聚集索引，创建索引的位置不同也会对查询效率不同（参考最左原则）
- 比如 select user_id from students order by user_age
- create index clust_ix(user_id, user_age)
- 比如 select user_id from students order by user_age
Shell 脚本中执行mysql语句
IBM Knowledge center DB2
Hive中HSQL中left semi join和INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN区别