爱华网1、触发器不会返回结果，但是它可以读取或修改数据。因此，可以使用触发器代替客户端代码来强制约束（Constraint）或保证商业逻辑;2、如果你习惯于在其他数据库产品中广泛地使用触发器，那么就应该假设它在MySQL中不会按照同样的方式工作，尤其是：（1）对于每个事件，在每个表上只能有一个触发器。换句话说，不会有两个触发器启动AFTER INSERT事件。（2）MySQL只支持行级触发器，也就是说，服务器总是针对每一行进行操作，而不是把它们看成一个整体。这使得处理大型数据集的效率很差。下面这些针对触发器的通用警示条款也适用于MySQL：（1）它们让服务器正在做的事情变得模糊，因为一个简单的语句也可能导致很多“不可见”的工作。例如，如果一个触发器更新了一个相关的表，那么受影响的行的数量就会加倍。（2）触发器很难调试，并且它也不利于分析性能。（3）触发器会引起不明显的死锁和锁等待。如果触发器失败了，原始查询也会失败，如果没意识到触发器的存在，就很难准确地解释错误码。3、触发器也不能保持原子性。例如，一个更新 MyISAM 表的触发器发生了错误，但却无法回滚。假设在一个MyISAM 表中使用AFTER UPDATE 触发器更新另外一个MyISAM 表，如果触发器发生错误，导致第二个表更新失败，但第一个表的更新却不会被回滚。4、InnoDB 表上的触发器的所有操作都在一个事务中完成，所以触发器和引发它的操作是原子操作。 事件
1、事件和连接完全无关，它运行在一个独立的定时器线程上。事件不接受参数，也不返回值，也没有任何连接让它们可以得到输入或返回输出。2、适合事件的任务包括周期性的维护工作、重新建立缓存和汇总表以模拟物化视图，或者保存用于监视和诊断的状态值。3、尽管事件和连接无关，但它和线程有关。服务器有一个主调度线程，必须用配置文件或利用命令把它激活，一旦激活了它，每执行一个事件，都会创建一个新线程。 游标
1、MySQL现在提供了只能向前的只读游标（Cursor），它只能在存储过程中使用。一个存储过程在同一时刻可以使用多个游标，也可以在循环中嵌套游标。2、MySQL以后也许会提供用于更新的游标，但现在没有。因为游标读取的是临时表，而不是产生数据的原始表，所以它是只读的。用户自定义函数
1、MySQL支持用户自定义函数（UDF, User-Defined Functions）已经有很长时间了。UDF 和用SQL语句写的存储函数不同，它可以用任何支持C 调用方式的编程语言来写。2、如果使用了UDF，升级MySQL的时候要仔细地检查版本间的不同，也许需要对它进行重新编译，甚至得做出改变才能和新版本兼容。同时要保证 UDF是绝对线程安全的，它们在 MySQL服务器进程里面运行，那是纯粹的多线程环境。3、和SQL 语言写成的存储函数不同，UDF现在不能读写表，至少在调用上下文中不行。这意味着它对纯计算，或者是和外部的交互非常有帮助。视图
1、视图（View）是很普通的概念，MySQL 5.0包含了这一特性。MySQL视图就像一张表，但其自身不会存储任何数据，它的数据来自SQL查询语句。出于很多考虑，MySQL把视图当成表来看待，并且两者共享了同样的命名空间。（mysql是用C语言写成的一个软件）。但是MySQL处理它们的方式并不完全一样。例如，不能在视图上创建触发器，也不能用DROP TABLE 命令删除视图。2、MySQL可以使用这两种执行方式，它们分别调用了合并算法（MERGEAlgorithm）和临时表算法（TEMPTABLEAlgorithm)。MySQL会优先考虑使用合并算法。它甚至可以合并嵌套的视图。3、在视图包含GROUP BY、DISTINCT 、聚集函数、UNION、子查询或其他无法保持视图返回的行和待查询的行之间一对一关系的结构的时候，MySQL就会使用临时表算法。4、可更新视图可以通过视图更新它所引用的表，视图如果含有GROUP BY 、UNION、聚集函数或任何其他的异常，就不是可更新的。使用TEMPTABLE算法的视图是不可更新的。构造临时表的查询不会从外部查询中得到WHERE条件，并且临时表没有索引。5、有时可以使用伪临时视图取得好的效果。这不用创建一个只在当前连接中存在的真正临时视图，而是用一种特殊的方式，比如在特定的数据库中，创建一个视图，接下来就可以在FROM子句中使用这个视图，在使用完之后就可以把它删除。6、MySQL不支持物化视图（MaterializedView）。物化视图通常把结果存储在一个不可见的表里面，然后周期性地从原始数据对不可见表进行刷新。MySQL也不支持索引视图（Indexed View ），可以通过创建缓存表和汇总表模拟物化视图和索引视图。7、MySQL对视图的实现有一些让人烦恼的地方。最大的问题是MySQL不会保持视图的原始SQL 语句。如果试着使用SHOWCREATE VIEW 命令把视图显示出来，然后对它进行编辑，你会非常惊讶。 字符集1、UTF -8 多字节字符集以可变字节数（1 字节到3字节）来保存每个字符。MySQL内部许多字符串操作使用了固定大小的缓冲区，所以它必须分配足够的空间，以容纳最大的可能长度。例如，CHAR(10)使用UTF -8 进行编码，即使实际的字符串没有所谓的宽字符，也需要30 个字节。2、另外一个出人意料的地方就是索引限制。如果索引了一个使用了UTF -8 字符集的列，MySQL就会假设每个字符都会是3字节，所以平常的长度限制突然就减少为三分之一。3、某些人推荐在所有的地方都使用UTF -8 。但是，如果在意性能的话，这不是一个好主意。许多应用程序根本不需要UTF -8，并且使用何种字符集依赖于数据。UTF -8 使用更多的磁盘空间。 全文索引
1、在MySQL中，只有MyISAM 存储引擎支持全文索引。尽管只有MyISAM 支持全文索引，如果想使用InnoDB或其他存储引擎，也不用担心，因为你可以自己做全文索引。一个通常的办法就是把表复制到从服务器上，它可以使用 MyISAM存储引擎，然后使用从服务器进行全文搜索。如果不想在不同的服务器上处理查询，可以把表垂直地分为两部分，一部分保留文本列，另一部分保留其余的数据。2、如果定义了MATCH()函数两次，也不会有额外的开销，MySQL知道它们是同样的函数，只会执行一次。但是，如果在ORDER BY子句中使用了MATCH()，MySQL会使用文件排序来对结果进行排序。3、布尔全文搜索的结果是没有排序的。4、短语搜索很慢。只靠全文索引无法响应这种搜索，因为索引没有在原始的全文集合中记录单词之间的相对位置。这样造成的结果就是服务器不得不到行内部去执行单词搜索。5、布尔全文搜索实际不需要全文索引。如果有全文索引的话，它就会使用索引，如果没有的话，它就会扫描整个表。甚至可以对多个表使用布尔全文搜索，例如对联接的结果进行搜索。但是在所有的情况下，它都很慢。6、MySQL全文索引只会按照频率进行相关性排序。索引不会记录被索引的单词在字符串中的位置，所以即使单词相邻，也不会对相关性有贡献。尽管这对大多数应用都没有问题，尤其是数据量较小的时候，但是这仍然有可能无法达到需求，并且MySQL全文索引没有提供自由选择排名算法的可能。它甚至没有把用于相邻性排名的数据保存起来。7、如果正在向数据库导入大量的数据并且希望全文索引某些列，那么在导入之前就应该使用DISABLE KEYS禁止全文索引，然后在导入后再用ENABLE KEYS重新启用它。这通常会更快，因为为插入的每一行更新索引需要很多时间，并且这样还可以避免碎片产生。8、InnoDB 现在是主要的支持外键的存储引擎。 合并表和分区表
1、合并表其实并不是一个真正的表，它更像一个用于放置相似表的容器，可以使用合并存储引擎创建合并表。相反的是，分区表是一个正常的表，它包含了一些特殊的指令，告诉MySQL物理数据被存放在什么地方，每个分区实际都是有索引的独立表，分区表其实包装了很多句柄对象。分区表看上去像一个单独的表，但它实际上是一大堆独立的表，但是无法访问分区表下面的独立表，不过合并表可以。2、MySQL在对分区表和合并表的实现上有很多共通之处，它们也有同样的限制，两个特性都会带来同样的好处，它们可以让你做到下面这些事情： 分离静态的和变化的数据。 使用相关数据的物理相邻性来优化查询。 设计表以便查询访问较少的数据。 更容易地维护非常多的数据。（合并表在这个领域上比分区表更有优势）3、注意到合并表包含的表列的数量和类型都是一样的，并且合并表上的索引也会在下属表上存在。这是创建合并表的要求。4、合并表还有其他有趣的特性和限制，比如删除合并表或它的某个下属表。删除合并表让所有的“子表”都变得不可访问，但是删除其中的某个子表有不同的影响，它的行为和操作系统有关。例如，在GNU/Linux 上，子表的文件描述符还保持开启的状态，并且表还继续存在，但是只能从合并表中访问。5、创建合并表的CREATE语句不会检查下属表是否是兼容的。如果下属表的定义有轻微的不一样，MySQL会创建合并表，但是却无法使用。同样，如果在创建了一个有效的合并表之后对某个下属表进行了改变，它也会无法工作，并且会显示下面的错误信息：“ERROR 1168 （HY000 ）：无法打开定义不同的下属表，或者非MyISAM表，或者不存在的表”6、使用合并表的注意事项：(1)一旦唯一键和主键查询成功，它们就立即停止。在这种情况下，服务器会挨个访问下属表，一旦查找到了值，就不会再查找更多的表。(2) 下属表读取的顺序和CREATTABLE语句中定义的一致。如果经常需要按照特定的顺序取得数据，可以利用这种特性使合并排序操作更快。7、合并表非常适合但是并非只对日志和大量数据有效。它可以方便地按需创建繁忙的表。创建和删除合并表的代价是很低的。索引可以像对视图使用UNIONALL命令那样使用合并表。但它的开销更低，因为服务器不会把结果放到临时表中然后再传递给客户端。这使得它对于报告和仓库化数据非常有用。例如，要创建一个每晚都会运行的任务，它会把昨天的数据和8天前、15天前、以及之前的每一周的数据进行合并。使用合并表就可以创建无须修改的查询，并且自动地访问合适的数据。甚至还可以创建临时合并表，这是视图无法做到的。8、MySQL隐藏了分区表的分区，并只能通过分区表访问所有的分区，可以创建只包含想要的数据的临时合并表，例如某个特定时间段的数据。这是分区表无法做到的。9、分区表和合并表有一个重大的区别：任何一个给定的数据行只会被存储在一个合适的分区上。表的定义基于分区函数（PartitioningFunction)，它约定了行和分区之间的映射关系。10、分区表的局限：(1) 当前，所有的分区都要使用同样的存储引擎。例如，不能像合并表那样只压缩部分分区;(2) 尽管MySQL能避免分区表的查询访问所有的分区，但是它仍然锁定了所有的分区;(3) 分区不支持外键(4)分区表的灵活程度在某种程度上比合并表要小一些。例如想给分区表添加索引，这个操作并不能在一小段时间内完成，因为ALTER会将表锁住，并且重新构建整个表。合并表有更多的灵活性，比如可以给一个下属表添加索引。同样地，不能一次只备份或恢复一个分区，但是合并表没有这个限制。 分布式（XA）事务
1、XA事务需要事务协调员，它会通知所有的参与者准备提交事务（阶段一）。当协调员从所有参与者那里收到“就绪（R eady）”信号时，它会通知所有参与者进行真正的提交（阶段二）。MySQL可以是XA事务的参与者，但不能是协调员。2、内部分布式事务：MySQL内部使用XA事务的原因是服务器和存储引擎之间是隔离的。存储引擎之间是完全独立的，彼此不知道对方的存在，所以任何跨引擎的事务本质上都是分布的，并且要求第三方来进行协调。MySQL就是第三方。假如没有XA事务，跨引擎事务提交需要顺序地要求每个引擎进行提交。这样就会引入一种可能，就是在某个引擎提交之后发生了崩溃，但是另外一个引擎还未提交。这就打破了事务的原则。3、MySQL不擅长分布式数据处理，因为它缺少并行查询的执行能力。 综合
1、与持久性连接相比，连接池在连接策略上有更多的控制。你可以把一个连接池配置成自动扩充的，但是通常的做法还是当连接池满的时候，新的连接请求都被放在队列里等待。这使得这些请求都在应用服务器上等待，总好过MySQL因为连接太多而超载。2、优化Apache的web程序的途径:(1) 不要把Apache用作静态内容的服务，如果一定要用，那也至少要换个另外的Apache实例来处理这些事情。常见的替代品有lighttpd 和nginx;(2)使用一个缓存代理服务器，比如Squid 或Varnish，使用户请求无须抵达Web服务器后才能被响应。即使在这个层面上你无法缓存所有的页面，你也能缓存大部分页面，并通过Edge Side Includes（ESL，http://www.esi.org ）技术把页面上的小块动态部分放到缓存的静态部分里。(3)对动态内容和静态内容都设置过期策略。你可以使用缓存代理软件，像Squid，去验证内容的明确性。Wikipedia就是用这样的技术在缓存里移除内容已发生变化的文档(4)不要将Apache上的长距离连接配置为“保活”（Keep-Alive）模式，因为它会使Apache上臃肿的进程长时间处于运行状态。代替的方案是，用一个服务端的代理来处理“保活”的连接，使服务器免受这类客户端的伤害。如果将Apache与代理之间的连接方式设为“保活”，那是不错的主意，因为代理仅使用几个连接从服务器上读取数据。
另外补充一些自己的体验：（1）mysql表中的记录数没有限制，即使操作系统对文件大小设置了限制（毕竟mysql表最终是存储在磁盘上的文件），但是由于linux虚拟分区的概念，不会造成此问题。只是说表里面的记录数太多的话，会影响查询效率和排除故障的效率；（2）mysql查询表的列中explain 表名 等于 show columns from 表名 也等于describe表名。如果在SELECT语句前放上关键词EXPLAIN，MySQL将解释它如何处理SELECT，提供有关表如何联接和联接的次序。结果字段的解释:Table: 显示该语句涉及数据库表Type: 这列很重要， 显示了该连接使用了哪种类别， 有无使用索引，反应语句的质量 。结果值从好到坏依次是 : system > const > eq_ref >ref > fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range > index > ALL， 一般来说，得保证查询至少达到range级别， 最好能到达ref级别， 否则就可能出现性能问题。Possible_key : 指出mysql能使用哪个索引在该表中找到行Key: 显示mysql实际使用的键（索引）, 如果没有选择索引， 键是null。Key_len ： 显示mysql决定使用的键长度。 如果是null， 则长度为null，在不损失精确性的情况下，长度越短越好。Ref： 显示使用哪个列或常数与key一起从表中选择行。Rows: 显示mysql认为它执行查询时必须检查的行数。Extra ： 包含mysql解决查询的详细信息。（3）查看 mysql版本：（1）打开终端，输入：mysql -V（2）登录mysql，在mysql里面直接输入 status
