16.”order by”是如何工作的？

17.如何正确的显示随机消息？

18.为什么这些SQL语句逻辑相同，性能却差异巨大？

可能此SQL语句对索引的字段进行了显式或隐式的函数操作，使得索引有序性被破坏，优化器放弃树搜索，开始全扫描扫描，因此性能变差了…

• 显式的函数操作
• 隐式类型转换
• 隐式字符编码转换

19.

20.幻读是什么，有什么问题吗？

21.为什么我只改一行的语句，锁这么多？

22.MySQL有哪些”饮鸩止渴”临时性地提升性能的方法？

业务高峰期时，生产环境的MySQL由于短连接数突增、慢查询、QPS突增等问题，没法正常响应，需要临时性地提升一些性能。

• 在机器负载比较高时，处理现有请求的时间变长，导致每个连接保持的时间也更长，这时候再有新连接就会使短连接数居高不下，如果连接数超过了max_connections限制就会使业务端认为”此数据不可用”。为了应对这种问题，可以考虑处理掉那些占着连接却不工作的线程，如设置wait-timeout参数断开超时空闲的线程或者直接使用kill connection + id主动在服务端踢掉不在事务执行中的线程。客户端收到服务端主动断开的消息是有延迟的，且连接断开是非常常见的事，因此业务开发时须有正确地重连和重试机制！
• 慢查询问题可能由未设计好索引、未写好SQL命令以及MySQL选错了索引等原因造成，针对未设计好索引可基于Online-DDL在线紧急创建索引，而未写好SQL命令以致未使用索引或者MySQL选错了索引，导致最终出现慢查询问题，可使用MySQL的查询重写功能修改SQL语句。当然针对慢查询问题最好的方案还是做好预防措施，在生产环境上线前先在测试环境做好测试。
• 有时某个新功能出现bug可能导致QPS突增，此时最理想的情况就是将新服务下线了…

24.MySQL如何保证主备一致？

25.

26.

27.

28.

29.

30.用动态的观点看加锁

• 查询过程中访问到的对象才加锁。

• 加锁的基本单位为next-key lock，前开后闭区间。

  • 优化1：索引上的等值查询，给唯一索引加锁时，next-key lock会退化为行锁。

  • 优化2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件时，next-key退化为间隙锁。

• 唯一索引上的范围查询会访问到不满足条件的第一个值为止。

• 范围查询先定位边界(值存在且符合条件，加next-key lock；值存在但不符合条件，加间隙锁；值不存在，对值所在间隙加间隙锁)，然后根据边界选择向左还是向右遍历；

• 在执行查询过程中，通过树搜索的方式定位记录的时候，用的是等值查询；找到记录后遍历数据，就不再是等值查询了…