数据库优化 （持续更新中）

禁止转载！本文只为个人看法，具体相关优化需根据数据库版本及数据量级实际操作为准。

1.使用like关键字 前面加%一般不走索引，如果查询的字段为在覆盖索引字段内就会走  后面加走索引（数据量多不走）

2.经过普通运算或函数运算后的索引字段不能使用索引

3.is null,is not null,!=,<>,like %后面   需要看数据库版本，数据量等具体情况才能知道走不走索引

4.一个加了索引的表中频繁更新或者插入或者删除，索引会降低其性能，这时候就要使用读写分离

5.枚举类型的字段不用加索引（例如：性别，月份）

6.子查询一般都会指数查询，外层查询多少次嵌套的查询也会查询多少次非常影响性能。尽量用Left join right join代替

7.死锁和阻塞

  死锁（例子：1，2号同时更新AB表，更新的顺序不同）

1号先更新A表，A表被锁，去更新B表的时候，因为2号在更新B表，所以B表被锁，不能完成更新，2号更新A表，A表被1号锁住所以造成了死锁...

解决：与团队达成一致更新顺序，或者都由一个人来完成这个业务

阻塞（例子：1，2号同时更新A表）

8.字符串固定长度的时候（比如：身份证，手机号）字段类型可以用char，char是固定长度，vachar长度不是固定的，所以char处理速度比vachar要快一些

9.mysql一行的最大长度为8090字节（也就是7.9KB）如果数据过长会换行。例如：某个字段存储文章时，这是就要考虑单独建表来存。

10.in exists之间相互替换

1. SELECT  *  from  t_message WHERE  id  in (SELECT  id  from  t_user)

2. SELECT *  from  t_message t1 WHERE  EXISTS(SELECT  *  from  t_user t2 WHERE  t1.id=t2.id)

in是把t_message 和t_user做hash连接，先查询t_user在将其结果与t_message 匹配。如果t_message的数据量远大于t_user，t_message.id使用索引。使用第一条SQL语句。

exists是先对t_message进行loop循环，每次loop循环在对t_user进行查询。如果t_user的数据量远大于t_message，t_user.id使用索引。使用第二条SQL语句。

而not in则是对t_message和t_user进行全表扫描，无法使用索引，可使用not exists代替或t_message left join t_user on t_message .id=t_user .id。具体的选择需实际操作决定。

11.公用表表达式(CTE)

公用表表达式（CTE）是一个命名的临时结果集，它存在于单个语句的范围内，以后可以在该语句中引用，可能多次。

主要作用就是写法清晰并可递归

普通例子

WITH cte1 AS

(SELECT a, b FROM table1), cte2 AS (SELECT c, d FROM table2)

SELECT b, d FROM cte1 JOIN cte2 WHERE cte1.a = cte2.c;

递归例子

WITH RECURSIVE cte (n) AS

( SELECT 1 UNION ALL SELECT n + 1 FROM cte LIMIT 10000 )

SELECT * FROM cte;

<