MySQL索引采用的是B+TREE，多列联合索引是一个有序元组<a1, a2, …, an>，其中各个元素均为数据表的一列。设一个表有M列，建一个度为n的多列联合索引，深度h = lognM，设一组索引列的大小为s，索引文件的大小可以计算为s*M*（1+M/n+M/n2+M/n3+。。。。）
SQLServer索引可以include非索引列，include的最大好处是这些列只需要在叶子节点存在，索引可以有效减小索引文件的大小，同时一个页面上可以存储更多的内节点，提高减少磁盘IO。
MySQL等数据库的索引为什么使用B+TREE而不是B-TREE，一种说法是由于B+Tree内节点去掉了data域，因此可以拥有更大的出度，拥有更好的性能。也就是说，B+Tree内节点去掉了data域，内节点占用更少的空间，一个页内可以放更多的叶子节点，因此可以拥有更大的出度。并列出出度的公式：
dmax = floor(pagesize / (keysize + datasize + pointsize)) (pagesize – dmax >= pointsize)
或
dmax = floor(pagesize / (keysize + datasize + pointsize)) – 1 (pagesize – dmax < pointsize)
这种解释感觉起来有点勉强，公式也觉得奇怪，出度和pagesize有什么关系呢？出度应该会有更多的考虑吧，一个1w行表的索引和100000w行表索引的出度不能设成一样吧，比如都是1000，那1w行表用索引的意义就不大了。索引又不会放到一个page上。我觉得正确的解释是这样：由于B+Tree内节点去掉了data域，这样一个页上可以存储更多的内节点，也就有可能存储多个层级的内节点（比如前3层），这样前3次索引查询只需要一次磁盘IO，和SQLServer索引可以include非索引列原理类似，只不过SQLServer做得更好罢了。