MySQL排序问题
排序的时候，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。对于这个sql select city,name,age from t where city=‘杭州’ order by name limit 1000 ;
city是索引字段，对于这种查询
（1）初始化 sort_buffer，确定放入 name、city、age 这三个字段；
（2）从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID_X；（3）到主键 id 索引取出整行，取 name、city、age 三个字段的值，存入 sort_buffer 中；
（4）从索引 city 取下一个记录的主键 id；
（5）重复步骤 3、4 直到 city 的值不满足查询条件为止，对应的主键 id 也就是图中的 ID_Y；
（6）对 sort_buffer 中的数据按照字段 name 做快速排序；
（7）按照排序结果取前 1000 行返回给客户端。
这是全字段排序，所有的查询字段都放到sort_buffer 中
这是sort_buffer 内存足够的情况，对于内存不够的时候，会使用外部排序，使用磁盘的文件辅助排序最后归并。
当然，因为将所有的select的字段放入sort_buffer 中，内存很有可能就不够，SET max_length_for_sort_data = 16;这个sql就可以使用rowid排序，既是将id 和排序的列放到sort_buffer 中，然后根据这些排序好之后，再进行id回表查询其他字段返回，因为会再去原表取值，所以会多查询所需要的1000的数据
这两种排序，一般内存足够的话建议全字段排序，效率会相对高一些
对于排序，一般来说数据量较大的话，建议加上索引，因为索引是天然有序的，可以省略排序的过程，考虑到返回三个字段，可以考虑联合索引，这样可以覆盖索引，减少回表
短时间优化问题
1.短连接风暴
正常的短连接模式就是连接到数据库后，执行很少的 SQL 语句就断开，下次需要的时候再重连。如果使用的是短连接，在业务高峰期的时候，就可能出现连接数突然暴涨的情况。一旦数据库处理得慢一些，连接数就会暴涨。max_connections 参数，用来控制一个 MySQL 实例同时存在的连接数的上限，超过这个值，系统就会拒绝接下来的连接请求，并报错提示“Too many connections”。
碰到这种情况时，一个比较自然的想法，就是调高 max_connections 的值。但这样做是有风险的。因为设计 max_connections 这个参数的目的是想保护 MySQL，如果我们把它改得太大，让更多的连接都可以进来，那么系统的负载可能会进一步加大，大量的资源耗费在权限验证等逻辑上，结果可能是适得其反，已经连接的线程拿不到 CPU 资源去执行业务的 SQL 请求。
这种有风险的，怎么处理
（1）第一种方法：先处理掉那些占着连接但是不工作的线程。
从服务端断开连接使用的是 kill connection + id 的命令， 一个客户端处于 sleep 状态时，它的连接被服务端主动断开后，这个客户端并不会马上知道。直到客户端在发起下一个请求的时候，才会收到这样的报错“ERROR 2013 (HY000): Lost connection to MySQL server during query”。从数据库端主动断开连接可能是有损的，尤其是有的应用端收到这个错误后，不重新连接，而是直接用这个已经不能用的句柄重试查询。这会导致从应用端看上去，“MySQL 一直没恢复”。
（2）减少连接过程的消耗。
有的业务代码会在短时间内先大量申请数据库连接做备用，如果现在数据库确认是被连接行为打挂了，那么一种可能的做法，是让数据库跳过权限验证阶段。跳过权限验证的方法是：重启数据库，并使用–skip-grant-tables 参数启动。这样，整个 MySQL 会跳过所有的权限验证阶段，包括连接过程和语句执行过程在内。但是，这种方法风险极高
2.慢查询性能问题
索引没有设计好；SQL 语句没写好；MySQL 选错了索引。
备注：参考极客时间MySQL45讲做的笔记
