其实不应该为了某些特殊的场景配置特殊的配置，只有当发现特定的性能问题才应该去设置它们。优化最好是从查询语句和响应时间入手来开始分析问题，而不是通过配置项。最好的还是使用默认的配置，毕竟默认配置是经过最多实际测试的。
1.服务器接收SQL,以SQL和一些其他条件为key查找缓存表(额外性能消耗）
2.如果找到了缓存,则直接返回缓存(性能提升)
2.如果没有找到缓存,则执行SQL查询,包括原来的SQL解析,优化等.
4. 执行完SQL查询结果以后,将SQL查询结果存入缓存表(额外性能消耗)
缓存存在一个hash表中,通过查询SQL,查询数据库,客户端协议等作为key.在判断是否命中前,MySQL不会解析SQL,而是直接使用SQL去查询缓存,SQL任何字符上的不同,如空格,注释,都会导致缓存不命中.
如果查询中有不确定数据,例如CURRENT_DATE()和NOW()函数,那么查询完毕后则不会被缓存.所以,包含不确定数据的查询是肯定不会找到可用缓存的
在服务端只需要解析一次SQL语句。
在服务端某些优化器的工作只需要执行一次，因为它会缓存一部分的执行计划。
以二进制的方式只发送参数和句柄，比每次发送ASCII码文本效率更高。
当创建一个绑定变量SQL时，客户端向服务器发送了一个SQL语句的原型。服务器端收到这个SQL语句框架后，解析并存储这个SQL语句的部分执行计划，返回给客户端一个SQL语句处理句柄。以后每次执行这类查询，客户端都指定使用这个句柄。
编写MySQL的存储代码困难。
较之应用程序的代码，存储代码效率要稍微差些，难以实现复杂的逻辑。
MySQL并没有什么选项可以控制存储程序的资源消耗，所以在存储过程中的一个小错误，可能直接把服务器拖死。
服务器内部执行，节省带宽和网络延迟。
代码重用，统一业务。
简化代码的维护和版本更新。
InnoDB是目前MySQL中唯一支持外键的内置存储引擎。使用外键是有成本的，如果向子表中写入一条记录，外键约束会让InnoDB检查对应的父表的记录，也就需要对父表对应记录进行加锁操作，InnoDB强制外键使用索引，但是无法消除要检查多个表的这种开销，要是索引的选择性低了，那就慢了。
不过外键约束在保持数据的一致性有着更好的作用，比应用层面来控制要好得多。
在数据量超大的时候，B-Tree索引就无法起作用了。除非是索引覆盖查询，否则数据库需要根据索引扫描的结果回表，查询所有符合条件的记录，如果数据量巨大，这将产生大量的随机I/O，随之，数据库的响应时间将大到不可接受的程度。另外，索引维护（磁盘空间，I/O操作）的代价也非常高。
分区表由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区。存储引擎管理分区的各个底层表和管理普通表一样，分区表的索引只是在各个底层表上各自加上一个完全相同的索引。
每个操作都会“先打开并锁定所有的底层表”，但这并不是说分区表在处理过程中是锁住全表的。如果存储引擎能够自己实现行级锁，例如InnoDB,则会在分区层释放对应的表锁。