目录
1、海量数据下，如何根据计划调优sql？
2、mysql索引体系如何应对海量数据存储？
数据持持久化存储到磁盘中，没有办法直接把全量的数据一次性读取到内存中，因此需要分块读取，每次读取一部分。
磁盘预读：磁盘跟内存在进行交互的时候有一个最基本的逻辑单位称之为页，也叫作datapage，页的大小一般与操作系统相关，一般是4k或者8k，我们在进行数据数据读取的时候，一般会读取页的整数倍。例如mysql中的innodb引擎默认一次性读取16k。所以需要上面描述的分块读取。
2.1 如何设计索引结构？需要考虑什么？
如果我们设计一个索引结构应该考虑如下图所示问题，主要包括数据格式，数据结构和io性能：
用各种数据结构设计索引的缺点：
哈希表：
二叉树：
B树：
B+树：
B+树索引一般都有几层？
一般情况下，3-4层的B+树足以支撑千万级别的数据量存储。选择索引列的时候尽可能选择占用空间小的key值，key值占用空间越小，存储的数据量越大。
1.一个表可以创建多少个索引？
很多个
2.一个索引对应一颗B+树还是多个索引对应一颗？
一个索引对应一颗
3、聚簇索引和非聚簇索引全解析。
我们知道在B+树的叶子结点中存储实际的数据，那么当一张表中存在多个索引的时候，数据存储几份？
如果是1份的话，那么其他索引的叶子结点存储什么信息呢？
mysql的官方解释是primarykey，但是这个东西不能直接翻译为主键，因为在mysql的innodb存储引擎中，每一条记录的插入必须跟某一个索引存储在一起。如果表中有主键，那么数据就会和主键存储在一起，如果没有主键，那么会选择唯一间进行存储，如果没有唯一键，那么mysql会生成6字节的rowid进行存储。也就是说，mysql的数据存储只有一份，那么跟数据绑定存储的索引为聚簇索引，而没有跟数据绑定的存储称之为非聚簇索引。
4、回表，索引覆盖，最左匹配
回表
检索了两次b+树，效率低，不推荐使用，很多情况下mysql用到了索引但是查询慢，很多就是因为回表问题。
索引覆盖
如果查询语句变为 select id,name,age就会涉及回表。索引覆盖效率高，推荐使用。
最左匹配
1,2,4用到了组合索引。其中4如果查询结果一样，mysql优化器会对其进行优化。
现在看下面这种情况：
表abc：
该表中的组合索引涉及到表中的所有字段，发生了索引覆盖现象，所以就不遵守最左匹配原则。
5、如何针对特定的sql场景，来进行索引的调优？
1346
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
