网站制作建设百度搜索热度查询

sql 书写顺序与执行顺序

(7) SELECT
(8) DISTINCT <select_list>
(1) FROM  <main_table>
(3) <join_type> JOIN <join_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) HAVING <having_condition>
(9) ORDER BY <order_by_condition>
(10) LIMIT <limit_number>

SQL设计优化

使用索引

• 确保对经常作为查询条件的列创建索引
• 对JOIN的列创建索引
• 但要注意不要过度索引，因为这会减慢写操作（如INSERT、UPDATE、DELETE）。

避免索引失效

• 匹配前缀：如果在WHERE子句中使用LIKE操作符，且匹配模式的开始部分是通配符（例如LIKE ‘%xyz’），将不会使用索引。但如果是’xyz%'，则使用索引。
• 使用函数或表达式：在列上使用函数或表达式（例如WHERE YEAR(column) = 2021）会导致索引失效，因为MySQL无法利用索引直接定位数据
• OR条件：or表达式两边都必须有索引才会走索引，否则将不会走索引。
  
• 反向条件不走索引 != 、 <> 、 NOT IN、IS NOT NULL
• 数据类型不一致，隐式转换（可能）导致索引失效【这点在隐式类型转换中有场景演示】
  

分析慢查询

• 使用EXPLAIN关键字可以帮助你分析SQL查询的执行计划。通过分析，你可以发现潜在的性能瓶颈，如全表扫描、没有使用索引等问题。

合理使用子查询和临时表

• 子查询和临时表如果不当使用，会造成性能问题。在可能的情况下，尝试使用JOIN来替代它们。

列相关使用

• 使用最适合数据的最小数据类型，如INT、VARCHAR等，这可以减少磁盘IO，提高查询效率。

• 尽量避免使用SELECT *，而是明确指定需要查询的字段。这不仅可以减少数据传输量，还能提高查询效率。

日常SQL优化场景

limit语句

SELECT *
FROM   operation
WHERE  type = 'SQLStats'AND name = 'SlowLog'
ORDER  BY create_time
LIMIT  1000, 10;

在优化上面SQL时，如果数据量特别庞大，除了在type, name, create_time 字段上加组合索引，还可以记录上一次返回列表最后一条数据，以它为开始，优化后（并不会根据数据量的增长而发生变化）：

SELECT   *
FROM     operation
WHERE    type = 'SQLStats'
AND      name = 'SlowLog'
AND      create_time > '2017-03-16 14:00:00'
ORDER BY create_time limit 10;

隐式类型转换

隐式转换，就是不带转换类型的转换，当一个字段类型为varchar，但是在判断时SQL是用int去判断，MySQL 就会对这个int进行隐式转换，将其int类型转换为varchar

-- salecode 为varchar类型  
explain select * from my_distribute where salecode=898

在上述例子中，salecode为varchar类型，其列有索引，但是SQL并没有使用索引，是因为SQL中发生了隐式转换，导致了全表扫描，那是不是所有隐式转换都会使索引失效？

-- address 为int类型  
explain select * from my_distribute where address='22'

还是同一个表，address类型为int，其列有索引，但是SQL却使用索引[address]，以上可知，隐式转换不一定会导致索引失效，而是根据索引的类型变化，如果是数值类型，则右边无论是数值还是字符串都可以走索引，但是我们在开发中，一定要格外注意，避免隐式转换索引失效

嵌套子查询

UPDATE operation o
SET    status = 'applying'
WHERE  o.id IN (SELECT idFROM   (SELECT o.id,o.statusFROM   operation oWHERE  o.group = 123AND o.status NOT IN ( 'done' )ORDER  BY o.parent,o.idLIMIT  1) t);

上述例子中，更新operation使用了子查询去做过滤，并且使用了in条件，子查询将会在检索operation每一条数据时，都会执行一遍子查询，并将结果集返回判断operation的o.id是否在结果集中，效率非常低下，我们在开发中，也尽量使用join去替代子查询，改良后的sql：

UPDATE operation oJOIN  (SELECT o.id,o.statusFROM   operation oWHERE  o.group = 123AND o.status NOT IN ( 'done' )ORDER  BY o.parent,o.idLIMIT  1) tON o.id = t.id
SET    status = 'applying'

混合排序

MySQL 不能利用索引进行混合排序。但在某些场景，还是有机会使用特殊方法提升性能的。

SELECT *
FROM   my_order o
INNER JOIN my_appraise a ON a.orderid = o.id
ORDER  BY a.is_reply ASC,a.appraise_time DESC
LIMIT  0, 20

由于 is_reply 只有0和1两种状态，可以按照下面的方法重写：

SELECT *
FROM   ((SELECT *FROM   my_order oINNER JOIN my_appraise aON a.orderid = o.idAND is_reply = 0ORDER  BY appraise_time DESCLIMIT  0, 20)UNION ALL(SELECT *FROM   my_order oINNER JOIN my_appraise aON a.orderid = o.idAND is_reply = 1ORDER  BY appraise_time DESCLIMIT  0, 20)) t
ORDER  BY  is_reply ASC,appraisetime DESC
LIMIT  20;

使用表子查询，将两个查询结果集UNION ALL 合并结果实现排序

查询重写

 SELECTa.*,c.allocated 
FROM(SELECT resourceid FROM my_distribute d WHERE isdelete = 0 AND cusmanagercode = '22353' ORDER BY salecode LIMIT 20 ) aLEFT JOIN ( SELECT resourcesid, sum( ifnull( allocated, 0 )* 12345 ) allocated FROM my_resources GROUP BY resourcesid ) c ON a.resourceid = c.resourcesid

以上SQL中因为c表使用了全表聚合，导致了数据全表扫描10w数据，优化后：

SELECTr.resourcesid,sum( ifnull( allocated, 0 ) * 12345 ) allocated 
FROMmy_resources r,( SELECT resourceid, cusmanagercode FROM my_distribute d WHERE isdelete = 0 AND cusmanagercode = '22353' ORDER BY salecode LIMIT 20 ) a 
WHEREr.resourcesid = a.resourceid 
GROUP BYresourceid