单表数据量超大的时候，B-Tree索引就无法起作用了：
B-Tree索引扫描结果后（除覆盖索引外）都要回表查询，如果数据量巨大，将产生大量的随机I/O，使得数据库响应时间达到不可接受的程度。
维护索引的代价非常高。
1：分区表
粗粒度的，简易的索引策略，适用于大数据量的过滤场景；
最适合的场景是，在没有合适的索引时，对其中几个分区进行全表扫描，或者只有一个分区和索引是热点，而且这个分区和索引能够都在内存中；
分区表对于单条记录的查询并没有什么优势。
2：视图
本身是虚拟表，不存放任何数据，访问视图的时候，它返回的数据是从其他表中年生成的。
不支持在视图中构建索引。
视图并不总是有很优化的实现。
3：外键约束
innodb是目前mysql中唯一支持外键的内置存储引擎。
外键通常要求在修改数据时都要在另外一张表中执行一次查找操作。
innodb强制外键使用索引，外键列的选择性要高。
如果只是用外键做约束，在应用程序中实现该约束更好，外键会带来很大的额外消耗。
4：在mysql内部存储代码
存储过程和函数
mysql本身实现了存储过程，触发器，存储函数和事件，通常可以节省很多的网络开销。很多情况下，减少网络开销可以大大的提升系统的性能。
5：游标
只读，单向，指向临时表中的对象，在存储过程或更底层的客户端API中使用
mysql不支持客户端的游标，不过客户端API可以通过缓存全部结果的方式模拟客户端的游标，这和直接将结果放在一个内存数组中来维护并没有什么不同。
6：绑定变量
服务端缓存sql语句的部分执行计划，客户端通过句柄复用执行计划
insert into tb1(col,col2,col3) values ( ?,?,?);
以二进制的方式只发送参数和句柄
绑定变量是会话级别的，连接之间不能共用。
当查询语句的解析和执行计划生成消耗了主要的时间，那么绑定变量可以在一定程度上解决问题。
7：用户自定义函数(user define function)
8：插件
9：字符集和校对
char_set_client -> char_set_connection->char_set_result
10： 全文索引
11：分布式事务
引擎层的事务支持
内部XA事务：跨存储引擎的事务
外部XA事务：mysql能够作为参与者完成一个外部的分布式事务
12：查询缓存
缓存完成的select结果。
根据经验，在高并发压力环境中查询缓存会导致系统性能的下降，甚至僵死。
网友评论