Mysql优化思路及注意点

1：使用索引时要注意什么

多个查询时使用联合索引；

联合索引生效的规则；

聚簇索引与非聚簇索引的区别；

回行；

索引的长度；

like,not in,!等的使用；

索引建立在where且识别度高的列，不要太多所以，减少冗余索引。

2：MYsql优化思路

观看性能是否有周期性变化，是不是缓存失效，或者高峰引起

（加缓存或则会修改缓存失效策略，3-9小时的随机失效时间，查询mysql建立缓存，设置一个redis锁，有锁才可创建缓存）

=》出现不规则的延迟

=》show processlist或者开启慢查询找到sql->explain分析扫描效果或者profiling分析语句

=》1:等待的时间长（缓存区线程数调大）2:语句执行时间长（表关联多，设计不合理，索引优化，语句优化）

3：红黑树相对于哈希表，在选择使用的时候有什么依据

权衡三个因素: 查找速度, 数据量, 内存使用，可扩展性。

总体来说，hash查找速度会比map快，而且查找速度基本和数据量大小无关，属于常数级别;而map的查找速度是log(n)级别。并不一定常数就比log(n) 小，hash还有hash函数的耗时。如果考虑效率，特别是在元素达到一定数量级时，考虑考虑hash。但若你对内存使用特别严格， 希望程序尽可能少消耗内存，那么一定要小心，hash可能会让你陷入尴尬，特别是当你的hash对象特别多时，你就更无法控制了，而且 hash的构造速度较慢。

红黑树并不适应所有应用树的领域。如果数据基本上是静态的，那么让他们待在他们能够插入，并且不影响平衡的地方会具有更好的性能。如果数据完全是静态的，例如，做一个哈希表，性能可能会更好一些。

红黑树的应用场景：

二分查找，map

4：为什么数据库用b+树不用b树和红黑树或者Hash表

首先说红黑树为什么不行：

1.红黑树必须存在内存里的，数据库表太大了，存不进去。

2.即使你找到了把红黑树存进硬盘的方法，红黑树查找一个节点最多要查logN层，每一层都是一个内存页（虽然你只是想找一个节点，但硬盘必须一次读一个页。。），那么一共logN次IO，伤不起阿！

所以我们必须考虑减少树的层数来减少IO次数从而加快查询、修改数据库效率，b和b+树都符合这样的性质，它们每个节点的孩子都很多（几十~几千），所以整个树的高度可以压的很低。

比如100000000数据，每个节点有1000个孩子，那么log 1000(100000000)<3，3层就足够存了！

b+树，从增删改查，主要是查方面考虑，

数组：删除更改查找都很快，但是数组是一块连续的内存，中间插入要后移数据，严重拖慢速度。

哈希表对于删除、查找、更新、插入操作，都是先根据 key 计算出一个值，就能定位到数据的目标位置了，时间复杂度都是 O(1)，但是范围查找直接就有问题

二叉树：平衡二叉树，红黑树：缺点一个节点2个字节点，如果数据量大，树的高度很高，每一层都是一次i/o，查询树读太慢

b+和b-都有多个字节点，但是b-不仅有索引还有数据库，导致存的索引树还是小于b+,而且b+还可以对叶子节点增加链表，查询排序更方便

注意磁盘读数据读一个字节和读10个字节和读一页时间相差不大的（因为磁盘查找时间大多数都花在寻道上，旋转基本不费时）

再说b树为什么不如b+树：

1.b树的内部节点都是存储实际数据的，比如一个节点是一个页4096字节，其中每条数据128字节，那么一个节点只能存32个数据项，那么对应的孩子节点数最多为33个，这显然不够用。而b+树内部节点只作为导向作用，只存一个整数就可以，4096/4=1024个数据项。这样b+树的每个节点的孩子数更多，整个树的高度就更低，大大增加查询效率。

2.b+树的叶子节点有链表相连，适合范围查询，因为相邻页直接读取就好了。但b树做不到这一点。