有时候，我们希望将 MySQL 的 relay log 多保留一段时间，比如用于高可用切换后的数据补齐，于是就会设置 relay_log_purge=0，禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话：

Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.

   究竟是什么样的风险呢？查找了一番后，基本上明白了原因。

   首先，为了让从库是 crash safe 的，必须设置 relay_log_recovery=1，这个选项的作用是，在 MySQL 崩溃或人工重启后，由于 IO 线程无法保证记录的从主库读取的 binlog 位置的正确性，因此，就不管 master_info 中记录的位置，而是根据  relay_log_info 中记录的已执行的 binlog 位置从主库下载，并让 SQL …

0、导读

   MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全？

   MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全。

   数据安全如果只靠MySQL应用层面显然是不够的，是需要在多个层面来保护的，包括网络、系统、逻辑应用层、数据库层等。

   下面是我们可借鉴的一些安全策略。

1、网络、系统层面

   在这个层面可以做很多的事情，我们可以把这些安全要求作为新系统安装时的标准要求，放到自动化装机方案中。

• 把运行MySQL的服务器放在内网中，不要启用公网；

• …

   在mysql中limit可以实现快速分页，但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了，否则可能卡死你的服务器哦。

   当一个表数据有几百万的数据的时候成了问题！

   如 * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢，可以按照一下方法解决

    第一页会很快

   PERCONA PERFORMANCE CONFERENCE 2009上，来自雅虎的几位工程师带来了一篇”EfficientPagination Using MySQL”的报告

   limit10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。

   LIMIT 451350 , 30 扫描了45万多行，怪不得慢的都堵死了。

   但是

   limit 30 …

   备注：插图来自网络搜索，如果觉得不当还请及时告知 ：)

   一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式(以InnoDB引擎为主)完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。

   ORACLE MySQL 5.6版本开始支持多线程复制，配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制。不过，它只能支持一个实例下多个 database 间的并发复制，并不能真正做到多表并发复制。因此在较大并发负载时，slave还是没有办法及时追上master，需要想办法进行优化。

  …

   一般而言，我们在processlist结果中如果经常能看到某些SQL的话，至少可以说明这些SQL的频率很高，通常需要对这些SQL进行进一步优化。

   今天我们要说的是，在processlist中，看到哪些运行状态时要引起关注，主要有下面几个：

在创建新表和数据仓库时，要做很多决定。一些在当时似乎无关紧要的地方，却让你和用户在数据库的生命期内感到痛苦。

我们和成千上万的人们以及他们的数据库一道工作，经历了长期的读写查询，我们差不多看到了每种情况。下面是创建免去痛苦模式的 10 条规则。

1.只使用小写字母、数字和下划线

不要在数据库、模式、表或列名中使用点(dot)、空格、或连接号【注1】。点用于标示对象，通常以 database.schema.table.column 的方式。

对象名称中包含点将引起混淆。类似地，在对象名字里使用空格将迫使你在查询语句中添加不必要的引号：

select "user name" from events
  
-- vs
  
select user_name from events

如果在表或列名里有大写字母，查询语句将难以书写。如果所有字母都是小写的，人们将不必记住 users …

   通常，我们会出于以下几个目的对MySQL进行压力测试：

1、确认新的MySQL版本性能相比之前差异多大，比如从5.6变成5.7，或者从官方版本改成Percona分支版本；
2、确认新的服务器性能是否更高，能高多少，比如CPU升级了、阵列卡cache加大了、从机械盘换成SSD盘了；
3、确认一些新的参数调整后，对性能影响多少，比如 innodb_flush_log_at_trx_commit、sync_binlog 等参数；
4、确认即将上线的新业务对MySQL负载影响多少，是否能承载得住，是否需要对服务器进行扩容或升级配置；

   针对上面这几种压测的目的，相应的测试方法也有所不同。

   先说第四种，需要和线上业务结合起来，这时候就需要自行开发测试工具，或者利用 tcpcopy …

前言

   mysql的索引合并并不是什么新特性。早在mysql5.0版本就已经实现。之所以还写这篇博文，是因为好多人还一直保留着一条sql语句只能使用一个索引的错误观念。本文会通过一些示例来说明如何使用索引合并。

什么是索引合并

   下面我们看下mysql文档中对索引合并的说明：

The Index Merge method is used to retrieve rows with several range scans and to merge their results into one. The merge can produce unions, intersections, or unions-of-intersections of its underlying scans. This access method merges index scans from a single table; it does not merge scans across multiple tables.

   根据官方文档中的说明，我们可以了解到：

   1、索引合并是把几个索引的范围扫描合并成一个索引。

  …

索引目的

   索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？

索引原理

   除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。

  …

   大多数MySQL规范在网上也都能找得到相关的分享，在这里要分享的是老叶个人认为比较重要的，或者容易被忽视的，以及容易被混淆的一些地方。

   1、默认使用InnoDB引擎

   【老叶观点】已多次呼吁过了，InnoDB适用于几乎99%的MySQL应用场景，而且在MySQL 5.7的系统表都改成InnoDB了，还有什么理由再死守MyISAM呢。

   此外，频繁读写的InnoDB表，一定要使用具有自增/顺序特征的整型作为显式主键。

   【参考】：[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键。

   2、字符集选择utf-8

  …