缓存可以发生在这些层次：

• MySQL 内部：在系统调优参数介绍了相关设置；
• 数据访问层：比如 MyBatis 针对 SQL 语句做缓存，而 Hibernate 可以精确到单个记录，这里缓存的对象主要是持久化对象Persistence Object；
• 应用服务层：这里可以通过编程手段对缓存做到更精准的控制和更多的实现策略，这里缓存的对象是数据传输对象Data Transfer Object；
• Web 层：针对 web 页面做缓存；
• 浏览器客户端：用户端的缓存。

可以根据实际情况在一个层次或多个层次结合加入缓存。这里重点介绍下服务层的缓存实现，目前主要有两种方式：

• 直写式（Write Through）：在数据写入数据库后，同时更新缓存，维持数据库与缓存的一致性。这也是当前大多数应用缓存框架如 Spring Cache 的工作方式。这种实现非常简单，同步好，但效率一般；
• 回写式（Write Back）：当有数据要写入数据库时，只会更新缓存，然后异步批量的将缓存数据同步到数据库上。这种实现比较复杂，需要较多的应用逻辑，同时可能会产生数据库与缓存的不同步，但效率非常高。

MySQL 在 5.1 版引入的分区是一种简单的水平拆分，用户需要在建表的时候加上分区参数，对应用是透明的无需修改代码。

对用户来说，分区表是一个独立的逻辑表，但是底层由多个物理子表组成，实现分区的代码实际上是通过对一组底层表的对象封装，但对 SQL 层来说是一个完全封装底层的黑盒子。MySQL 实现分区的方式也意味着索引也是按照分区的子表定义，没有全局索引。

用户的 SQL 语句是需要针对分区表做优化，SQL 条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，可以通过EXPLAIN PARTITIONS来查看某条 SQL 语句会落在那些分区上，从而进行 SQL 优化.

分区的好处是：

• 可以让单表存储更多的数据；
• 分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作；
• 部分查询能够从查询条件确定只落在少数分区上，速度会很快；
• 分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
• 可以使用分区表赖避免某些特殊瓶颈，例如 InnoDB 单个索引的互斥访问、ext3 文件系统的 inode 锁竞争；
• 可以备份和恢复单个分区。

分区的限制和缺点：

• 一个表最多只能有 1024 个分区；
• 如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来；
• 分区表无法使用外键约束；
• NULL 值会使分区过滤无效；
• 所有分区必须使用相同的存储引擎。

分区的类型：

• RANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区；
• LIST 分区：类似于按 RANGE 分区，区别在于 LIST 分区是基于列值匹配一个离散值集合中的某个值来进行选择；
• HASH 分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含 MySQL 中有效的、产生非负整数值的任何表达式；
• KEY 分区：类似于按 HASH 分区，区别在于 KEY 分区只支持计算一列或多列，且 MySQL 服务器提供其自身的哈希函数。必须有一列或多列包含整数值。

分区适合的场景有：

• 最适合的场景数据的时间序列性比较强，则可以按时间来分区，如下所示：

• 查询时加上时间范围条件效率会非常高，同时对于不需要的历史数据能很容易的批量删除。

如果数据有明显的热点，而且除了这部分数据，其他数据很少被访问到，那么可以将热点数据单独放在一个分区，让这个分区的数据能够有机会都缓存在内存中，查询时只访问一个很小的分区表，能够有效使用索引和缓存。

另外 MySQL 有一种早期的简单的分区实现 – 合并表（merge table），限制较多且缺乏优化，不建议使用，应该用新的分区机制来替代。

垂直分库是根据数据库里面的数据表的相关性进行拆分，比如：一个数据库里面既存在用户数据，又存在订单数据，那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。垂直分表是对数据表进行垂直拆分的一种方式，常见的是把一个多字段的大表按常用字段和非常用字段进行拆分，每个表里面的数据记录数一般情况下是相同的，只是字段不一样，使用主键关联。

比如原始的用户表是：

垂直拆分后是：

垂直拆分的优点是：

• 可以使得行数据变小，一个数据块 (Block) 就能存放更多的数据，在查询时就会减少 I/O 次数 (每次查询时读取的 Block 就少)；
• 可以达到最大化利用 Cache 的目的，具体在垂直拆分的时候可以将不常变的字段放一起，将经常改变的放一起；
• 数据维护简单。

缺点是：

• 主键出现冗余，需要管理冗余列；
• 会引起表连接 JOIN 操作（增加 CPU 开销）可以通过在业务服务器上进行 join 来减少数据库压力；
• 依然存在单表数据量过大的问题（需要水平拆分）；
• 事务处理复杂。

水平拆分是通过某种策略将数据分片来存储，分库内分表和分库两部分，每片数据会分散到不同的 MySQL 表或库，达到分布式的效果，能够支持非常大的数据量。前面的表分区本质上也是一种特殊的库内分表。

库内分表，仅仅是单纯的解决了单一表数据过大的问题，由于没有把表的数据分布到不同的机器上，因此对于减轻 MySQL 服务器的压力来说，并没有太大的作用，大家还是竞争同一个物理机上的 IO、CPU、网络，这个就要通过分库来解决。

前面垂直拆分的用户表如果进行水平拆分，结果是：

实际情况中往往会是垂直拆分和水平拆分的结合，即将 Users_A_M 和 Users_N_Z 再拆成 Users 和 UserExtras，这样一共四张表。

水平拆分的优点是:

• 不存在单库大数据和高并发的性能瓶颈；
• 应用端改造较少；
• 提高了系统的稳定性和负载能力。

缺点是：

• 分片事务一致性难以解决；
• 跨节点 Join 性能差，逻辑复杂；
• 数据多次扩展难度跟维护量极大。

分片原则

• 能不分就不分，参考单表优化；
• 分片数量尽量少，分片尽量均匀分布在多个数据结点上，因为一个查询 SQL 跨分片越多，则总体性能越差，虽然要好于所有数据在一个分片的结果，只在必要的时候进行扩容，增加分片数量；
• 分片规则需要慎重选择做好提前规划，分片规则的选择，需要考虑数据的增长模式，数据的访问模式，分片关联性问题，以及分片扩容问题，最近的分片策略为范围分片，枚举分片，一致性 Hash 分片，这几种分片都有利于扩容；
• 尽量不要在一个事务中的 SQL 跨越多个分片，分布式事务一直是个不好处理的问题；
• 查询条件尽量优化，尽量避免 Select * 的方式，大量数据结果集下，会消耗大量带宽和 CPU 资源，查询尽量避免返回大量结果集，并且尽量为频繁使用的查询语句建立索引；
• 通过数据冗余和表分区赖降低跨库 Join 的可能。

这里特别强调一下分片规则的选择问题，如果某个表的数据有明显的时间特征，比如订单、交易记录等，则他们通常比较合适用时间范围分片，因为具有时效性的数据，我们往往关注其近期的数据，查询条件中往往带有时间字段进行过滤，比较好的方案是，当前活跃的数据，采用跨度比较短的时间段进行分片，而历史性的数据，则采用比较长的跨度存储。

总体上来说，分片的选择是取决于最频繁的查询 SQL 的条件，因为不带任何 Where 语句的查询 SQL，会遍历所有的分片，性能相对最差，因此这种 SQL 越多，对系统的影响越大，所以我们要尽量避免这种 SQL 的产生。

解决方案

由于水平拆分牵涉的逻辑比较复杂，当前也有了不少比较成熟的解决方案。这些方案分为两大类：客户端架构和代理架构。

客户端架构

通过修改数据访问层，如 JDBC、Data Source、MyBatis，通过配置来管理多个数据源，直连数据库，并在模块内完成数据的分片整合，一般以 Jar 包的方式呈现。

这是一个客户端架构的例子：

可以看到分片的实现是和应用服务器在一起的，通过修改 Spring JDBC 层来实现。

客户端架构的优点是：

• 应用直连数据库，降低外围系统依赖所带来的宕机风险；
• 集成成本低，无需额外运维的组件。

缺点是：

• 限于只能在数据库访问层上做文章，扩展性一般，对于比较复杂的系统可能会力不从心；
• 将分片逻辑的压力放在应用服务器上，造成额外风险。

代理架构

通过独立的中间件来统一管理所有数据源和数据分片整合，后端数据库集群对前端应用程序透明，需要独立部署和运维代理组件。

这是一个代理架构的例子：

代理组件为了分流和防止单点，一般以集群形式存在，同时可能需要 Zookeeper 之类的服务组件来管理。

代理架构的优点是：

• 能够处理非常复杂的需求，不受数据库访问层原来实现的限制，扩展性强；
• 对于应用服务器透明且没有增加任何额外负载。

缺点是：

• 需部署和运维独立的代理中间件，成本高；
• 应用需经过代理来连接数据库，网络上多了一跳，性能有损失且有额外风险。

各方案比较

如此多的方案，如何进行选择？可以按以下思路来考虑：

1. 确定是使用代理架构还是客户端架构。中小型规模或是比较简单的场景倾向于选择客户端架构，复杂场景或大规模系统倾向选择代理架构；
2. 具体功能是否满足，比如需要跨节点ORDER BY，那么支持该功能的优先考虑；
3. 不考虑一年内没有更新的产品，说明开发停滞，甚至无人维护和技术支持；
4. 最好按大公司 -> 社区 -> 小公司 -> 个人这样的出品方顺序来选择；
5. 选择口碑较好的，比如 github 星数、使用者数量质量和使用者反馈；
6. 开源的优先，往往项目有特殊需求可能需要改动源代码。

按照上述思路，推荐以下选择：

• 客户端架构：ShardingJDBC；
• 代理架构：MyCat 或者 Atlas。

目前也有一些开源数据库兼容 MySQL 协议，如：

• TiDB
• Cubrid

但其工业品质和 MySQL 尚有差距，且需要较大的运维投入，如果想将原始的 MySQL 迁移到可水平扩展的新数据库中，可以考虑一些云数据库：

• 阿里云 PetaData
• 阿里云 OceanBase
• 腾讯云 DCDB

一些数据规范:

一、基础规范

（1）必须使用InnoDB存储引擎

解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高

（2）必须使用UTF8字符集

解读：万国码，无需转码，无乱码风险，节省空间

（3）数据表、数据字段必须加入中文注释

解读：N年后谁tm知道这个r1,r2,r3字段是干嘛的

（4）禁止使用存储过程、视图、触发器、Event

解读：高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧

（5）禁止存储大文件或者大照片

解读：为何要让数据库做它不擅长的事情？大文件和照片存储在文件系统，数据库里存URI多好

二、命名规范

（6）只允许使用内网域名，而不是ip连接数据库

（7）线上环境、开发环境、测试环境数据库内网域名遵循命名规范

业务名称：xxx
线上环境：dj.xxx.db
开发环境：dj.xxx.rdb
测试环境：dj.xxx.tdb

从库在名称后加-s标识，备库在名称后加-ss标识

线上从库：dj.xxx-s.db
线上备库：dj.xxx-sss.db

（8）库名、表名、字段名：小写，下划线风格，不超过32个字符，必须见名知意，禁止拼音英文混用

（9）表名t_xxx，非唯一索引名idx_xxx，唯一索引名uniq_xxx

三、表设计规范

（10）单实例表数目必须小于500

（11）单表列数目必须小于30

（12）表必须有主键，例如自增主键

解读：

a）主键递增，数据行写入可以提高插入性能，可以避免page分裂，减少表碎片提升空间和内存的使用

b）主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型可以有效的减少索引的磁盘空间，提高索引的缓存效率

c） 无主键的表删除，在row模式的主从架构，会导致备库夯住

（13）禁止使用外键约束，可以冗余外键，如果有外键完整性约束，需要应用程序控制

解读：外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先

四、字段设计规范

（14）必须把字段定义为NOT NULL并且提供默认值

解读：

a）null的列使索引/索引统计/值比较都更加复杂，对MySQL来说更难优化

b）null 这种类型MySQL内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多

c）null值需要更多的存储空，无论是表还是索引中每行中的null的列都需要额外的空间来标识

d）对null 的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in这些操作符号。如：where name!=’shenjian’，如果存在name为null值的记录，查询结果就不会包含name为null值的记录

（15）禁止使用TEXT、BLOB类型

解读：会浪费更多的磁盘和内存空间，非必要的大量的大字段查询会淘汰掉热数据，导致内存命中率急剧降低，影响数据库性能

（16）禁止使用小数存储货币

解读：使用整数吧，小数容易导致钱对不上

（17）必须使用varchar(20)存储手机号

解读：

a）涉及到区号或者国家代号，可能出现+-()

b）手机号会去做数学运算么？

c）varchar可以支持模糊查询，例如：like“138%”

（18）禁止使用ENUM，可使用TINYINT代替

解读：

a）增加新的ENUM值要做DDL操作

b）ENUM的内部实际存储就是整数，你以为自己定义的是字符串？

五、索引设计规范

（19）单表索引建议控制在5个以内

（20）单索引字段数不允许超过5个

解读：字段超过5个时，实际已经起不到有效过滤数据的作用了

（21）禁止在更新十分频繁、区分度不高的属性上建立索引

解读：

a）更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能

b）“性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似

（22）建立组合索引，必须把区分度高的字段放在前面

解读：能够更加有效的过滤数据

六、SQL使用规范

（23）禁止使用SELECT *，只获取必要的字段，需要显示说明列属性

解读：

a）读取不需要的列会增加CPU、IO、NET消耗

b）不能有效的利用覆盖索引

c）使用SELECT *容易在增加或者删除字段后出现程序BUG

（24）禁止使用INSERT INTO t_xxx VALUES(xxx)，必须显示指定插入的列属性

解读：容易在增加或者删除字段后出现程序BUG

（25）禁止使用属性隐式转换

解读：SELECT uid FROM t_user WHERE phone=13812345678 会导致全表扫描，而不能命中phone索引，猜猜为什么？（这个线上问题不止出现过一次）

（26）禁止在WHERE条件的属性上使用函数或者表达式

解读：SELECT uid FROM t_user WHERE from_unixtime(day)>=’2017-02-15′ 会导致全表扫描

正确的写法是：SELECT uid FROM t_user WHERE day>= unix_timestamp(‘2017-02-15 00:00:00’)

（27）禁止负向查询，以及%开头的模糊查询

解读：

a）负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描

b）%开头的模糊查询，会导致全表扫描

（28）禁止大表使用JOIN查询，禁止大表使用子查询

解读：会产生临时表，消耗较多内存与CPU，极大影响数据库性能

（29）禁止使用OR条件，必须改为IN查询

解读：旧版本Mysql的OR查询是不能命中索引的，即使能命中索引，为何要让数据库耗费更多的CPU帮助实施查询优化呢？

（30）应用程序必须捕获SQL异常，并有相应处理

总结：大数据量高并发的互联网业务，极大影响数据库性能的都不让用，不让用哟。

补充：

军规：必须使用UTF8字符集

和DBA负责人确认后，纠正为“新库默认使用utf8mb4字符集”。

这点感谢网友的提醒，utf8mb4是utf8的超集，emoji表情以及部分不常见汉字在utf8下会表现为乱码，故需要升级至utf8mb4。

默认使用这个字符集的原因是：“标准，万国码，无需转码，无乱码风险”，并不“节省空间”。

一个潜在坑：阿里云上RDS服务如果要从utf8升级为utf8mb4，需要重启实例，所以58到家并没有把所有的数据库升级成这个字符集，而是“新库默认使用utf8mb4字符集”。

自搭的Mysql可以完成在线转换，而不需要重启数据库实例。

军规：数据表、数据字段必须加入中文注释

这一点应该没有疑问。

不过也有朋友提出，加入注释会方便黑客，建议“注释写在文档里，文档和数据库同步更新”。这个建议根据经验来说是不太靠谱的：

（1）不能怕bug就不写代码，怕黑客就不写注释，对吧？

（2）文档同步更新也不太现实，还是把注释写好，代码可读性做好更可行，互联网公司的文档管理？呆过互联网公司的同学估计都清楚。

军规：禁止使用存储过程、视图、触发器、Event

军规：禁止使用外键，如果有外键完整性约束，需要应用程序控制

军规：禁止大表使用JOIN查询，禁止大表使用子查询

很多网友提出，这些军规不合理，完全做到不可能。

如原文所述，58到家数据库30条军规的背景是“并发量大、数据量大的互联网业务”，这类业务架构设计的重点往往是吞吐量，性能优先（和钱相关的少部分业务是一致性优先），对数据库性能影响较大的数据库特性较少使用。这类场景的架构方向是“解放数据库CPU，把复杂逻辑计算放到服务层”，服务层具备更好的扩展性，容易实现“增机器就扩充性能”，数据库擅长存储与索引，勿让数据库背负过重的任务。

关于这个点，再有较真的柳岩小编就不回复了哈，任何事情都没有百分之百，但58到家的数据库使用确实没有存储过程、视图、触发器、外键、用户自定义函数，针对业务特性设计架构，等单库吞吐量到了几千上万，就明白这些军规的重要性啦。

军规：只允许使用内网域名，而不是ip连接数据库

这一点应该也没有疑问。

不只是数据库，缓存（memcache、redis）的连接，服务（service）的连接都必须使用内网域名，机器迁移/平滑升级/运维管理…太多太多的好处，如果朋友你还是采用ip直连的，赶紧升级到内网域名吧。

军规：禁止使用小数存储国币

有朋友问存储前乘以100，取出后除以100是否可行，个人建议“尽量少的使用除法”。

曾经踩过这样的坑，100元分3天摊销，每天摊销100/3元，结果得到3个33.33。后来实施对账系统，始终有几分钱对不齐，郁闷了很久（不是几分钱的事，是业务方质疑的眼神让研发很不爽），最后发现是除法惹的祸。

解决方案：使用“分”作为单位，这样数据库里就是整数了。

案例：SELECT uid FROM t_user WHERE phone=13812345678 会导致全表扫描，而不能命中phone索引

这个坑大家没踩过么？

phone是varchar类型，SQL语句带入的是整形，故不会命中索引，加个引号就好了：

SELECT uid FROM t_user WHERE phone=’13812345678’

军规：禁止使用负向查询NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描

此军规争议比较大，部分网友反馈不这么做很多业务实现不了，稍微解释一下：

一般来说，WHERE过滤条件不会只带这么一个“负向查询条件”，还会有其他过滤条件，举个例子：查询沈剑已完成订单之外的订单（好拗口）：

SELECT oid FROM t_order WHERE uid=123 AND status != 1;

订单表5000w数据，但uid=123就会迅速的将数据量过滤到很少的级别（uid建立了索引），此时再接上一个负向的查询条件就无所谓了，扫描的行数本身就会很少。

但如果要查询所有已完成订单之外的订单：

SELECT oid FROM t_order WHERE status != 1;

这就挂了，立马CPU100%，status索引会失效，负向查询导致全表扫描。

末了，除了《58到家数据库30条军规解读》中提到的基础规范、命名规范、表设计规范、字段设计规范、索引设计规范、SQL使用规范，还有一个行为规范的军规：

（31）禁止使用应用程序配置文件内的帐号手工访问线上数据库

（32）禁止非DBA对线上数据库进行写操作，修改线上数据需要提交工单，由DBA执行，提交的SQL语句必须经过测试

（33）分配非DBA以只读帐号，必须通过VPN+跳板机访问授权的从库

（34）开发、测试、线上环境隔离

为什么要制定行为规范的军规呢，大伙的公司是不是有这样的情况：

任何研发、测试都有连接线上数据库的帐号？

是不是经常有这类误操作？

（1）本来只想update一条记录，where条件搞错，update了全部的记录

（2）本来只想delete几行记录，结果删多了，四下无人，再insert回去

（3）以为drop的是测试库，结果把线上库drop掉了

（4）以为操作的是分库x，结果SecureCRT开窗口太多，操作成了分库y

（5）写错配置文件，压力测试压到线上库了，生成了N多脏数据

错误的SQL 用法

1、LIMIT 语句

分页查询是最常用的场景之一，但也通常也是最容易出问题的地方。比如对于下面简单的语句，一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。

好吧，可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时，程序员仍然会抱怨：我只取10条记录为什么还是慢？

要知道数据库也并不知道第1000000条记录从什么地方开始，即使有索引也需要从头计算一次。出现这种性能问题，多数情形下是程序员偷懒了。

在前端数据浏览翻页，或者大数据分批导出等场景下，是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下：

在新设计下查询时间基本固定，不会随着数据量的增长而发生变化。

2、隐式转换

SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句：

其中字段 bpn 的定义为 varchar(20)，MySQL 的策略是将字符串转换为数字之后再比较。函数作用于表字段，索引失效。

上述情况可能是应用程序框架自动填入的参数，而不是程序员的原意。现在应用框架很多很繁杂，使用方便的同时也小心它可能给自己挖坑。

3、关联更新、删除
虽然 MySQL5.6 引入了物化特性，但需要特别注意它目前仅仅针对查询语句的优化。对于更新或删除需要手工重写成 JOIN。

比如下面 UPDATE 语句，MySQL 实际执行的是循环/嵌套子查询（DEPENDENT SUBQUERY)，其执行时间可想而知。

UPDATE operation o
SET status = ‘applying’
WHERE o.id IN (SELECT id
FROM (SELECT o.id,
o.status
FROM operation o
WHERE o.group = 123
AND o.status NOT IN ( ‘done’ )
ORDER BY o.parent,
o.id
LIMIT 1) t);

重写为 JOIN 之后，子查询的选择模式从 DEPENDENT SUBQUERY 变成 DERIVED，执行速度大大加快，从7秒降低到2毫秒。

UPDATE operation o
JOIN (SELECT o.id,
o.status
FROM operation o
WHERE o.group = 123
AND o.status NOT IN ( ‘done’ )
ORDER BY o.parent,
o.id
LIMIT 1) t
ON o.id = t.id
SET status = ‘applying’

4、混合排序

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两种状态，我们按照下面的方法重写后，执行时间从1.58秒降低到2毫秒。

SELECT *
FROM ((SELECT *
FROM my_order o
INNER JOIN my_appraise a
ON a.orderid = o.id
AND is_reply = 0
ORDER BY appraise_time DESC
LIMIT 0, 20)
UNION ALL
(SELECT *
FROM my_order o
INNER JOIN my_appraise a
ON a.orderid = o.id
AND is_reply = 1
ORDER BY appraise_time DESC
LIMIT 0, 20)) t
ORDER BY is_reply ASC,
appraisetime DESC
LIMIT 20;

5、EXISTS语句

MySQL 对待 EXISTS 子句时，仍然采用嵌套子查询的执行方式。如下面的 SQL 语句：

SELECT *
FROM my_neighbor n
LEFT JOIN my_neighbor_apply sra
ON n.id = sra.neighbor_id
AND sra.user_id = ‘xxx’
WHERE n.topic_status < 4
AND EXISTS(SELECT 1
FROM message_info m
WHERE n.id = m.neighbor_id
AND m.inuser = ‘xxx’)
AND n.topic_type <> 5

去掉 exists 更改为 join，能够避免嵌套子查询，将执行时间从1.93秒降低为1毫秒。

SELECT *
FROM my_neighbor n
INNER JOIN message_info m
ON n.id = m.neighbor_id
AND m.inuser = ‘xxx’
LEFT JOIN my_neighbor_apply sra
ON n.id = sra.neighbor_id
AND sra.user_id = ‘xxx’
WHERE n.topic_status < 4
AND n.topic_type <> 5

6、条件下推
外部查询条件不能够下推到复杂的视图或子查询的情况有：

聚合子查询；
含有 LIMIT 的子查询；
UNION 或 UNION ALL 子查询；
输出字段中的子查询；

如下面的语句，从执行计划可以看出其条件作用于聚合子查询之后：

SELECT *
FROM (SELECT target,
Count(*)
FROM operation
GROUP BY target) t
WHERE target = ‘rm-xxxx’

确定从语义上查询条件可以直接下推后，重写如下：

SELECT target,
Count(*)
FROM operation
WHERE target = ‘rm-xxxx’
GROUP BY target

7、提前缩小范围
先上初始 SQL 语句：

SELECT *
FROM my_order o
LEFT JOIN my_userinfo u
ON o.uid = u.uid
LEFT JOIN my_productinfo p
ON o.pid = p.pid
WHERE ( o.display = 0 )
AND ( o.ostaus = 1 )
ORDER BY o.selltime DESC
LIMIT 0, 15
该SQL语句原意是：先做一系列的左连接，然后排序取前15条记录。从执行计划也可以看出，最后一步估算排序记录数为90万，时间消耗为12秒。

由于最后 WHERE 条件以及排序均针对最左主表，因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下，执行时间缩小为1毫秒左右。

SELECT *
FROM (
SELECT *
FROM my_order o
WHERE ( o.display = 0 )
AND ( o.ostaus = 1 )
ORDER BY o.selltime DESC
LIMIT 0, 15
) o
LEFT JOIN my_userinfo u
ON o.uid = u.uid
LEFT JOIN my_productinfo p
ON o.pid = p.pid
ORDER BY o.selltime DESC
limit 0, 15
再检查执行计划：子查询物化后（select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万，但是利用了索引以及 LIMIT 子句后，实际执行时间变得很小。

8、中间结果集下推
再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件)：

SELECT a.*,
c.allocated
FROM (
SELECT resourceid
FROM my_distribute d
WHERE isdelete = 0
AND cusmanagercode = ‘1234567’
ORDER BY salecode limit 20) a
LEFT JOIN
(
SELECT resourcesid， sum(ifnull(allocation, 0) * 12345) allocated
FROM my_resources
GROUP BY resourcesid) c
ON a.resourceid = c.resourcesid
那么该语句还存在其它问题吗？不难看出子查询 c 是全表聚合查询，在表数量特别大的情况下会导致整个语句的性能下降。

其实对于子查询 c，左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下，执行时间从原来的2秒下降到2毫秒。

SELECT a.*,
c.allocated
FROM (
SELECT resourceid
FROM my_distribute d
WHERE isdelete = 0
AND cusmanagercode = ‘1234567’
ORDER BY salecode limit 20) a
LEFT JOIN
(
SELECT resourcesid， sum(ifnull(allocation, 0) * 12345) allocated
FROM my_resources r,
(
SELECT resourceid
FROM my_distribute d
WHERE isdelete = 0
AND cusmanagercode = ‘1234567’
ORDER BY salecode limit 20) a
WHERE r.resourcesid = a.resourcesid
GROUP BY resourcesid) c
ON a.resourceid = c.resourcesid

但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销，还使得整个语句显的繁杂。使用 WITH 语句再次重写：

WITH a AS
(
SELECT resourceid
FROM my_distribute d
WHERE isdelete = 0
AND cusmanagercode = ‘1234567’
ORDER BY salecode limit 20)
SELECT a.*,
c.allocated
FROM a
LEFT JOIN
(
SELECT resourcesid， sum(ifnull(allocation, 0) * 12345) allocated
FROM my_resources r,
a
WHERE r.resourcesid = a.resourcesid
GROUP BY resourcesid) c
ON a.resourceid = c.resourcesid

读写分离