【存储引擎】
InnoDB表引擎
- 默认事务型引擎，最重要最广泛的存储引擎，性能非常优秀。
- 数据存储在共享表空间，可以通过配置分开。
- 对主键查询的性能高于其他类型的存储引擎。
- 内部做了很多优化，从磁盘读取数据时自动在内存构建hash索引，插入数据时自动构建插入缓冲区。
- 通过一些机制和工具支持真正的热备份，支持崩溃后的安全恢复，支持行级锁，支持外键。
MyISAM表引擎
- mysql5.1版本之前的默认存储引擎 ，拥有全文索引、压缩、空间函数。
- 不支持事务和行级锁，支持表锁，不支持奔溃后的安全恢复。
- 表存储在两个文件，.MYD（数据文件）和.MYI（索引文件）。
- 设计简单，某些场景下性能很好。
其他的表引擎
- Archive、Blackhole、CVS、Memory
【索引】
索引对性能的影响：
- 大大减少服务器需要扫描的数据量，帮助服务器避免排序和临时表、将随机I/O变顺序I/O，大大提高查询速度，降低写的速度、占用磁盘
索引的使用场景：
- 小表：大部分情况下全表扫描效率更高。
- 中到大型表：索引非常有效。
- 特大型的表：建立和使用索引的代价随之增长，可以使用分区技术来解决
索引的类型：
- 一个表只能有一个主键索引，可以有多个唯一索引。
- 主键索引一定是唯一索引，唯一索引不是主键索引。
- 主键可以与外键构成参照完整性约束，防止数据不一致
对比说明：
- 普通索引 最基本的索引，没有任何约束限制
- 唯一索引 与普通索引类似，但是具有唯一性约束
- 主键索引 特殊的唯一索引，不允许有空值
- 组合索引 将多个列组合在一起创建索引，可以覆盖多个列
- 外键索引 只有InnoDB类型的表才可以使用外键索引，保证数据的一致性、完整性和实现级联操作
- 全文索引 MySQL自带的全文索引只能用于MyISAM，并且只能对英文进行全文索引
MySQL索引的创建原则：
- 最适合索引的列是在where子句中的列，或连接子句中的列而不是出现在select关键字后的列
- 索引列的基数越大。索引的效果越好
- 对字符串进行索引，应该制定一个前缀长度，可以节省大量的索引空间
- 根据情况创建复合索引，复合索引可以提高查询效率
- 避免创建过多索引，索引会额外占用磁盘空间，降低写操作效率
- 主键尽可能选择短的数据类型，可以有效减少索引的磁盘占用提高查询效率
MySQL索引的注意事项：
- 复合索引遵循前缀原则
- like查询。%不能在前，可以使用全文索引
- column is null可以使用索引
- 如果MySQL估计使用索引比全表扫描更慢，会放弃使用索引
- 如果or前的条件中的列有索引，后面的没有，索引都不会被用到
- 列类型是字符串，查询时一定要给值加引号，否则索引失效
【查询优化】
查找分析SQL查询慢的原因
- 记录慢查询日志： 分析查询日志，不要直接打开查询日志进行分析，这样比较浪费时间和精力，可以使用pt-query-digest工具进行分析
- 使用show profile： set profiling=1;开启，服务器上执行的所有语句会检测消耗的时间，存到临时表中（show profiles；show profiles for query 临时表ID）
- 使用show status： show status 会返回一些计数器，show global status 查看服务器级别的所有计数；有时根据这些计数，可以猜测出哪些操作代价较高或者消耗时间多
- 使用show processlist： 观察是否有大量线程处于不正常的状态
- 使用explain： 分析单条SQL语句
优化查询过程中的数据访问
- 访问数据太多导致查询性能下降
- 确定应用程序是否在检索大量超过需要的数据，可能是太多行或列
- 确认MySQL服务器是否在分析大量不必要的数据行
避免使用如下SQL语句：
- 查询不需要的记录，使用limit解决
- 多表关联返回全部列，指定A.id,B.age
- 总是取出全部列，SELECT * 会让优化器无法完成索引覆盖扫描的优化
- 注意：重复查询相同数据，可以缓存数据，下次直接读取缓存！
是否在扫描额外的记录？
- 使用explain来进行，如果发现查询需要扫描大量数据但只返回少数的行，可以通过如下技巧去优化：使用索引覆盖扫描，把所有用的列都放到索引中，这样存储引擎不需要回表获取对应行就可以返回结果
- 改变数据库和表的结构，修改数据表范式（冗余）。
- 重写SQL语句，让优化器可以以更优的方式执行查询
优化长难的查询语句
- 一个复杂查询还是多个简单查询？
- MYSQL内部每秒能扫描内存中上百万行数据，相比之下，响应数据给客户端就要慢得多
- 使用尽可能少的查询是好的，但是有时将一个大的查询分解为多个小的查询时很有必要的
切分查询：
- 将一个大的查询分为多个小的相同的查询
- 一次性删除1000万的数据要比一次删除一万，暂停一会的方案更加耗损服务器开销
分解关联查询：
- 可以将一条关联语句分解成多条SQL来执行
- 让缓存的效率更高
- 执行单个查询可以减少锁的竞争
- 在应用层做关联可以更容易对数据库进行拆分
优化特定类型的查询语句
- 优化count()查询：
- count( * )中*会忽略所有的列，直接统计所有列数，因此不要使用count(列名)
- MyISAM中，没有任何where条件的count( * )非常快
- 当有where条件，MyISAM的count统计不一定比其他表引擎快
优化方案：
- 可以使用explain查询近似值，用近似值替代count(*)
- 增加汇总表
- 使用缓存
优化关联查询：
- 确定on或者using子语句的列上有索引
- 确保group by和order by中只有一个表中的列，这样MySQL才有可能使用索引
优化子查询：
- 尽可能使用关联查询来替代，尽量少使用子查询
优化group by 和distinct：
- 这两种查询均可使用索引来优化，是最有效的优化方法
- 关联查询中，使用标识列进行分组的效率会更高
- 如果不需要order by,进行group by时使用order by null，MySQL不会再进行文件排序
- with rollup超级聚合，可以挪到应用程序处理
优化limit分页：
- limit偏移量大的时候，查询效率低
- 可以记录上一次查询的最大ID，下次查询时直接根据该ID来查询
优化UNION查询：
- UNION ALL的效率高于UNION
【MySQL高可扩展和高可用】
分区表的原理
- 对用户而言，分区表是一个独立的逻辑表，但是底层MySQL将其分成了多个物理子表，这对用户来说是透明的，每一个分区表都会使用一个独立的表文件。
- 创建表时使用partition by子句定义每个分区存放的数据，执行查询时，优化器会根据分区定义过滤那些没有我们需要数据的分区，这样查询只需要所需数据在的分区即可
- 分区的主要目的是将数据按照一个较粗的粒度分在不同的表中，这样可以将相关的数据存放在一起，而且如果想一次性删除整个分区的数据也很方便
适用场景：
- 表非常大，无法全部存在内存或者只在表最后有热点数据，其他都是历史数据
- 分区表的数据更易维护，可以对独立的分区进行独立的操作
- 分区表的数据可以再不同的机器上，从而高效适用资源
- 可以使用分区表来避免某些特殊的瓶颈
- 可以备份和恢复独立的分区
限制：
- 一个表最多只能有1024个分区
- 5.1版本中，分区表表达式必须是整数，5.5可以使用列分区
- 分区字段中如果有主键和唯一索引列，那么主键列和唯一列都必须包含进来
- 分区表中无法使用外键约束
- 需要对现有表的结构进行修改
- 所有分区都必须使用相同的存储引擎
- 分区函数中可以使用的函数和表达式会有一些限制
- 某些存储引擎不支持分区
- 对于MyISAM的分区表，不能使用load index into cache
- 对于MyISAM表，使用分区表时需要打开更多的文件描述
分库分表的原理
- 通过一些 hash 算法或者工具实现将一张数据表垂直或者水平进行物理切分。
适用场景：
- 单表记录条数达到百万或者千万级别时
- 解决表锁的问题
分表方式：
- 水平分割
- 垂直分表
分库分表缺点：
- 有些分表的策略基于应用层的逻辑算法，一旦逻辑算法改变，整个分表逻辑都会改变，扩展性较差
- 对于应用层来说，逻辑算法无疑会增加开发成本
[水平分表]
定义：表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度
使用场景:表中的数据本身就有独立性，例如表中分别记录各个地区的数据或者不同时期的数据，特别是有些数据常用，有些不常用，比如切分历史数据和活跃数据
需要把数据存放到多个介质上
缺点:给应用增加复杂度，通常查询时需要多个表名，查询所有数据都需要 union 操作
在许多数据库应用中，这种复杂性会超过带来的优点，查询时会增加读一个索引层的磁盘次数
[垂直分表]
定义：把主键和一些列放在一张表，然后把主键和另外的列放在另一张表中
使用场景:表中某些列常用，而另外一些列不常用
可以使数据行变小，一个数据页能存储更多数据，查询时减少 I/O 次数
缺点:管理冗余列，查询所有数据都需要JOIN操作
【MySQL的复制原理及负载均衡】
MySQL 主从复制工作原理：
- 在主库上把数据更改记录到二进制文件（即所有的写操作都记录到binlog）
- 从库将主库的日志复制到自己的中继日志
- 从库读取中继日志中的事件，将其重放到从库数据中，即执行了日志中的 SQL 语句
解决了哪些问题？
- 数据分布：随意停止或开始复制，并在不同地理位置分布数据备份
- 负载均衡：降低单个服务器的压力
- 高可用和故障切换：帮助应用程序避免单点失败
- 升级测试：可以使用更高版本的 MySQL 作为从库
思考题：
设定网站的用户数量在千万级，但是活跃用户的数量只有1%，如何通过优化数据库提高活跃用户的访问速度？
答：我们可以根据用户的活跃程度，把活跃的用户提取出来放到另外一张表里面，每次活跃的用户登陆的时候就直接到活跃用户表中进行查询，这样就提高了数据库的查询速度。
【MySQL安全性】
SQL查询的安全方案
1、使用预处理语句防SQL注入
2、写入数据库的数据要进行特殊字符的转义
3、查询错误信息不要返回给用户，将错误记录到日志
MySQL的其他安全设置
1、定期做数据备份
2、不给查询用户root权限，合理分配权限
3、关闭远程访问数据库权限
4、修改root口令，不用默认口令，使用较复杂的口令
5、删除多余的用户
6、改变root用户的名称
7、限制一般用户浏览其他库
8、限制用户对数据文件的访问权限