MySQL-高级特性

分区表

分区表是一个独立的逻辑表，底层由多个物理子表组成。实现分区的代码实际上是对一对底层表的句柄对象的封装。对分区表的请求，都会通过句柄对象转化成对存储引擎的接口调用。

MySQL实现分区表的方式-对底层表的封装-意味着索引也是按照分区的子表定义的，而没有全局索引。

MySQL在创建表时通过使用PARTITION BY子句定义每个分区存放的数据。分区的主要目的时将数据按照一个较粗的力度分在不同的表中。

分区应用场景：
表非常大以至于无法全部都放在内存中，或者旨在表的最后部分有热点数据，其他均是历史数据。
分区表的数据更容易维护。
分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。
可以使用分区表来避免某些特殊的瓶颈，InnoDB的单个索引的互斥访问。
可以备份和回复独立的分区，这在非常大的数据集的场景下效果非常好。

分区表的限制：
一个表最多只能有1024个分区。
在MySQL5.1中，分区表达式必须是整数，或者是返回整数的表达式。
如果分区字段中由主键或者唯一索引的列，那么所有主键列和唯一索引列必须包含进来。
分区表中无法使用外键约束。

分区表的操作逻辑：
SELECT查询 当查询一个分区表的时候，分区表先打开并锁住所有的底层表，优化器先判断是否可以过滤部分分区，然后在调用对应的存储引擎接口访问各个分区的数据。
INSERT：当写入一条记录时，分区层先打开并锁住所有的底层表，然后确定哪个分区接收这条记录，再将记录写入对应底层表。
DELETE：当删除一条记录时，分区层先打开并锁住所有的底层表，然后确定数据对应的分区，最后对应底层表进行删除操作。
UPDATE：当更新一条记录时，分区层先打开并锁住所有的底层表，MySQL 先确定需要更新的记录在那个分区，然后取出数据并更新，再判断更新后的数据应该放在哪个分区，最后对底层表进行写入操作，并对原始数据所在的底层表进行删除操作。

分区技术：范围分区，键值、哈希和列表分区，子分区，根据键值进行分区来减少InnoDB的互斥量竞争；使用数学函数模型来继续你滚分区，然后将数据轮询放入不同的分区；假设表有个自增的主键列id，希望根据时间将最近的热点数据集中存放。那么必须将时间戳包含在主键当中才行，而这和主键本身的意义相矛盾。

可扩展性策略：全量扫描数据，不要任何索引；索引数据，并分离热点

合并表

创建合并表：
create table t1(a int not null primary key) engine=myisam;
create table t2(a int not null primary key) engine=myisam;
create tabel mrg(a int not null priamry key) engine=myisam union=(t1,t2) insert_method=last;

合并表的限制：
在使用create语句创建一个合并表时，并不会检查各个子表的兼容性。如果子表定义稍有不同，那么MySQL就可能创建出一个后面无法使用的合并表。另外，如果在成功创建了合并表后在修改某个子表的定义，那么之后再使用合并表就可能会看到这样的报错：ERROR 1168
根据合并表的特性，不难发现，在合并表上面无法使用REPLACE语法，无法使用自增字段。
如果一个查询访问合并表，那么它需要访问所有子表。这会让根据键查找单行的查找速度变慢，如果能够只访问一个对应表，速度肯定将更快。

一些MySQL5.5分区所不能提供的特性：
一个myisam表可以是多个合并表的子表；
可以通过直接复制.frm,myi,myd文件，来实现在不同的服务器之间复制各个子表；
子啊合并表中可以很容易地添加性能的子表：直接修改合并表的定义就可以啦；
可以创建一个合并表，让他只包含需要的数据。
如果对某个子表做备份、恢复、修改、修复或者别的操作时，可以先将其从合并表中删除，操作结束后再将其加回去；
可以使用myisampack来压缩所有的子表。

视图

视图本身是一个虚拟表，不存放任何数据。在使用sql语句访问视图时，他返回的数据是MySQL从其他表中生成的。视图和表实在同一个命名看弓箭，MySQL在很多地方对于视图和表是同样对待的。

MySQL内部存储代码

MySQL允许通过触发器、存储过程、函数的形式来存储代码。

存储代码的优缺点：
它在服务器内部执行，离数据最近，另外在服务器上执行还可以节省宽带和网络延迟。
这是一种代码重用。可以方便统一业务规则保证某些行为总是一直，所以也可以为应用提供一定的安全性。
它可以简化代码的维护和版本更新。
它可以帮助提升安全，比如提供细粒度的权限控制。
服务器端可以缓存存储过程的执行计划，这对于需要反复调用的过程，会大大降低消耗。
因为是在服务器段部署的，所以备份、维护都可以在服务器端完成。所以在存储程序的维护工作会很简单。
它可以在应用开发和数据库开发人员之间更好地分工。

MySQL本身灭有提供好用的开发和调试工具，所以编写MySQL的代码存储比其他的数据库要难些。
较之应用程序的代码，存储代码效率要稍微差些。
存储代码可能会给应用程序代码的部署带来额外的复杂性。原来只需要部署应用代码和库表结构变更，现在还需要额外地部署MySQL内部的存储代码。
因为存储程序都部署在服务器内，所以可能有安全隐患。如果将非标准的加密功能放在存储代码中，那么如数据库被攻破，数据也就泄露啦。
存储过程会给数据库服务器增加额外的压力，而数据库服务器的扩展性相比应员工服务器压差很多。
MySQL并没有什么选项可以控制存储程序的资源消耗，所以在存储过程中的一个小错误，可能直接把服务器拖死。
存储代码在MySQL中的实现也有很多限制-执行计划缓存是连接级别的，游标的物化和临时表相同。
调试MySQL的存储过程是一件很困难的事情。
它和基于语句的二进制日志复制合作得不好。

MySQL架构问题

优化器无法使用关键字DETERMINISTIC来优化按个查询中多次调用存储函数的情况
优化器无法评估存储函数的执行成本。
每个连接都有独立的存储过程的执行计划缓存。如果有多个连接需要调用同一个存储过程将会浪费缓存空间来反复缓存同样的执行计划。
存储程序和复制是一组诡异组合。

触发器

对每一个表的每一个事件，最多只能定义一个触发器；
MySQL支持基于行的触发，也就是说触发器始终针对一条记录的，而不是针对整个sql语句的，如果变更的数据级非常大的话，效率很低。

命令设置：
set global event_scheduler:=1;

绑定变量可以高效执行语句：
在服务器端只需要解析一次SQL语句。
在服务器端某些优化工器的工作只需要执行一次，因为它会缓存一部分的执行计划。
以二进制的方式之发哦是那个参数和句柄，比起每次都发送ASCII码文本效率更高，一个二进制的日期字段只需要三个字节，但如果是ASCII码则需要十个字节。
仅仅是参数-而不是整个查询语句-需要发送到服务器端，所以网络开销会更小。
MySQL在存储参数的时候，直接将其放在缓存中，不再需要在内存中多次复制。

插件

存储过程插件：在存储过程后再处理一次运行结果。
后台插件：在MySQL运行时，可以实现自己的网络监听、执行自己的定期任务。
IINFORMATION_SCHEMA插件：提供一个新的内存INFORMATION_SCHEMA表。
审计插件：审计插件在查询执行的过程中的某些固定点被调用，所以它可以用作记录MySQL的事件日志。
认证插件：既可以在MySQL客户端也可以在它的服务器端，可以使用这类插件来扩展MySQL的认证功能。

字符集

MySQL的设置可以分为类：创建对象时的默认值、在服务器和客户端通信时的设置。

查询缓存需要注意的地方：
读查询在开始之前必须先检查是否命中缓存。
如果这个读查询可以被缓存，那么当完成执行后，MySQL若发现查询缓存中没有这个查询，会将器结果存入查询缓存，这会带来额外的系统消耗。
这对写操作也会有影响，因为当某个表写入数据的时候，MySQL必须将对应表的所有缓存都设置失效。如果查询缓存非常大或者碎片很多，这个操作就可能会带来很大系统消耗。

select语句没有从查询缓存中返回都称为“缓存为命中”。原因如下：
查询语句无法被缓存，可能是因为查询中包含一个不确定的函数或者查询结果太大而无法缓存，这都会导致状态值Qcache_not_cached增加。
MySQL从未处理这个查询，所以这个结果也不曾被缓存过。
还有一种情况是虽然之前缓存了查询结果，但是由于查询缓存的内存用完了，MySQL需要将某些缓存“逐出”，或者由于鼠标被修改导致缓存失效。

如果服务器上面有大量缓存未命中，但是实际上绝大多数查询都被换粗了，原因如下：
查询缓存还没有完成预热。也就是说，MySQL还没有机会将查询结果缓存起来。
查询语句之前从未执行过。如果你的应用程序不会重复执行一条查询语句，那么即使完成预热仍然会有很多缓存未命中。
缓存失效操作太多了。

配置和维护查询缓存

query_cache_type:off,on,demand
query_cache_size:单位是字节，1024的整数倍。
query_cache_min_res_unit:
query_cache_limit:
query_cache_wlock_invalidate:on,off