Manager of pid-file quit without updating file
================================================
1、mysql.sock路径不对或路径没有写权限
2、my.cnf配置有错误
3、数据库所在目录mysql不可读写
4、删除了二进制日志，需要删除
日志索引文件 General error: 3 Error writing file ‘/tmp/MYhJ0mvo’ (Errcode: 28) =================================================
tmp文件夹满了写入不了 解决：使用tmpdir指定新的空闲目录，或清理目录
Show命令的用法：
1. show tables或show tables from database_name; — 显示当前数据库中所有表的名称。
2. show databases; — 显示mysql中所有数据库的名称。
3. show columns from table_name from database_name; 或show columns from database_name.table_name; — 显示表中列名称。
4. show grants for user_name; — 显示一个用户的权限，显示结果类似于grant 命令。
5. show index from table_name; — 显示表的索引。
6. show status; — 显示一些系统特定资源的信息，例如，正在运行的线程数量。
7. show variables; — 显示系统变量的名称和值。
8. show processlist; — 显示系统中正在运行的所有进程，也就是当前正在执行的查询。大多数用户可以查看他们自己的进程，但是如果他们拥有process权限，就可以查看所有人的进程，包括密码。
9. show table status; — 显示当前使用或者指定的database中的每个表的信息。信息包括表类型和表的最新更新时间。
10. show privileges; — 显示服务器所支持的不同权限。
11. show create database database_name; — 显示create database 语句是否能够创建指定的数据库。
12. show create table table_name; — 显示create database 语句是否能够创建指定的数据库。
13. show engies; — 显示安装以后可用的存储引擎和默认引擎。
14. show innodb status; — 显示innoDB存储引擎的状态。
15. show logs; — 显示BDB存储引擎的日志。
16. show warnings; — 显示最后一个执行的语句所产生的错误、警告和通知。
17. show errors; — 只显示最后一个执行语句所产生的错误。
18. show [storage] engines; –显示安装后的可用存储引擎和默认引擎。
），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
本文主要探讨 mysqldump 的几种主要工作方式，并且比较一下和 mk-parralel-dump 的一些差异，为备份方式的选择提供更多的帮助。
首先来看下 mysqldump 的几个主要参数的实际工作方式。
081022 17:39:33 7 Connect root@localhost on 7 Query /*!40100 SET @@SQL_MODE='' */ 7 Init DB yejr 7 Query SHOW TABLES LIKE 'yejr' 7 Query LOCK TABLES `yejr` READ /*!32311 LOCAL */ 7 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 7 Query show create table `yejr` 7 Query show fields from `yejr` 7 Query show table status like 'yejr' 7 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 7 Query UNLOCK TABLES 7 Quit
2. –lock-tables
跟上面类似，不过多加了一个 READ LOCAL LOCK，该锁不会阻止读，也不会阻止新的数据插入。
081022 17:36:21 5 Connect root@localhost on 5 Query /*!40100 SET @@SQL_MODE='' */ 5 Init DB yejr 5 Query SHOW TABLES LIKE 'yejr' 5 Query LOCK TABLES `yejr` READ /*!32311 LOCAL */ 5 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 5 Query show create table `yejr` 5 Query show fields from `yejr` 5 Query show table status like 'yejr' 5 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 5 Query UNLOCK TABLES 5 Quit
3. –lock-all-tables
这个就有点不太一样了，它请求发起一个全局的读锁，会阻止对所有表的写入操作，以此来确保数据的一致性。备份完成后，该会话断开，会自动解锁。
081022 17:36:55 6 Connect root@localhost on 6 Query /*!40100 SET @@SQL_MODE='' */ 6 Query FLUSH TABLES 6 Query FLUSH TABLES WITH READ LOCK 6 Init DB yejr 6 Query SHOW TABLES LIKE 'yejr' 6 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 6 Query show create table `yejr` 6 Query show fields from `yejr` 6 Query show table status like 'yejr' 6 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 6 Quit
4. –master-data
除了和刚才的 –lock-all-tables 多了个 SHOW MASTER STATUS 之外，没有别的变化。
081022 17:59:02 1 Connect root@localhost on 1 Query /*!40100 SET @@SQL_MODE='' */ 1 Query FLUSH TABLES 1 Query FLUSH TABLES WITH READ LOCK 1 Query SHOW MASTER STATUS 1 Init DB yejr 1 Query SHOW TABLES LIKE 'yejr' 1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 1 Query show create table `yejr` 1 Query show fields from `yejr` 1 Query show table status like 'yejr' 1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 1 Quit
5. –single-transaction
InnoDB 表在备份时，通常启用选项 –single-transaction 来保证备份的一致性，实际上它的工作原理是设定本次会话的隔离级别为：REPEATABLE READ，以确保本次会话(dump)时，不会看到其他会话已经提交了的数据。
081022 17:23:35 1 Connect root@localhost on 1 Query /*!40100 SET @@SQL_MODE='' */ 1 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 1 Query BEGIN 1 Query UNLOCK TABLES 1 Init DB yejr 1 Query SHOW TABLES LIKE 'yejr' 1 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 1 Query show create table `yejr` 1 Query show fields from `yejr` 1 Query show table status like 'yejr' 1 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 1 Quit
6. –single-transaction and –master-data
本例中，由于增加了选项 –master-data，因此还需要提交一个快速的全局读锁。在这里，可以看到和上面的不同之处在于少了发起 BEGIN 来显式声明事务的开始。这里采用 START TRANSACTION WITH CONSISTENT SNAPSHOT 来代替 BEGIN 的做法的缘故不是太了解，可以看看源代码来分析下。
081022 17:27:07 2 Connect root@localhost on 2 Query /*!40100 SET @@SQL_MODE='' */ 2 Query FLUSH TABLES 2 Query FLUSH TABLES WITH READ LOCK 2 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 2 Query START TRANSACTION WITH CONSISTENT SNAPSHOT 2 Query SHOW MASTER STATUS 2 Query UNLOCK TABLES 2 Init DB yejr 2 Query SHOW TABLES LIKE 'yejr' 2 Query SET OPTION SQL_QUOTE_SHOW_CREATE=1 2 Query show create table `yejr` 2 Query show fields from `yejr` 2 Query show table status like 'yejr' 2 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `yejr` 2 Quit
关于隔离级别可以看手册 13.2.10.3. InnoDB and TRANSACTION ISOLATION LEVEL，或者本站之前的文章：[InnoDB系列] – 实例解析Innodb的隔离级别以及锁模式。
关于 START TRANSACTION WITH CONSISTENT SNAPSHOT 的说明可以看下手册描述：
The WITH CONSISTENT SNAPSHOT clause starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB table. See Section 13.2.10.4, “Consistent Non-Locking Read”. The WITH CONSISTENT SNAPSHOT clause does not change the current transaction isolation level, so it provides a consistent snapshot only if the current isolation level is one that allows consistent read (REPEATABLE READ or SERIALIZABLE).
12.4.1. START TRANSACTION, COMMIT, and ROLLBACK Syntax
mk-parralel-dump 是开源项目 Maatkit 中的一个工具，主要由 Baron Schwartz 维护。
mk-parralel-dump 是由 perl 开发的，可以实现并发的导出数据表。具体的功能不细说，自己去看相关文档吧。这里只列出在我的环境下和 mysqldump 的对比数据。
#导出耗时 time mysqldump -f --single-transaction -B yejr --tables yejr | gzip > /home/databak/yejr.sql.gz real 10m15.319s user 6m47.946s sys 0m38.496s #文件大小 608M /home/databak/yejr.sql.gz #导出期间系统负载 05:00:01 PM all 0.71 0.00 0.61 7.33 91.36 05:10:02 PM all 13.93 0.00 2.21 4.64 79.22
#导出耗时 time mysqldump -f --single-transaction -B yejr --tables yejr | gzip --fast > /home/databak/yejr_fast.sql.gz real 9m6.248s user 4m21.467s sys 0m37.604s #文件大小 815M Oct 21 17:33 /home/databak/yejr_fast.sql.gz #导出期间系统负载 05:20:01 PM all 11.94 0.00 2.43 5.69 79.94 05:30:01 PM all 6.46 0.00 1.57 3.95 88.02
time ./mk-parallel-dump --database yejr --tables yejr --basedir /home/databak/ default: 25 tables, 25 chunks, 25 successes, 0 failures, 404.93 wall-clock time, 613.25 dump time real 6m48.763s user 4m20.724s sys 0m38.125s #文件大小 819M /home/databak/default/yejr/ #导出期间系统负载 05:10:02 PM all 13.93 0.00 2.21 4.64 79.22 05:20:01 PM all 11.94 0.00 2.43 5.69 79.94
可以看到，mk-parallel-dump 尽快确实实现了并发导出，速度相对快多了，却有个致命伤：那就是它不支持InnoDB的一致性备份，目前已经有人提交相关代码了，不过还没实现，期待中
查询语句的优化
多多利用 “explain” 查询索引使用情况, 以便找出最佳的查询语句写法和索引设置方案
慎用 “select *”, 查询时只选出必须字段
查询使用索引时, 所遍历的索引条数越少, 索引字段长度越小, 查询效率越高 (可使用 “explain” 查询索引使用情况)
避免使用 mysql 函数对查询结果进行处理, 将这些处理交给客户端程序负责
使用 “limit” 时候, 尽量使 “limit” 出的部分位于整个结果集的前部, 这样的查询速度更快, 系统资源开销更低
在 “where” 子句中使用多个字段的 “and” 条件时, 各个字段出现的先后顺序要与多字段索引中的顺序相符
在 “where” 子句 中使用 “like” 时, 只有当通配符不出现在条件的最左端时才会使用索引
在 mysql 4.1 以上版本中, 避免使用子查询, 尽量使用 “内/外连接” 实现此功能
减少函数的使用, 如果可能的话, 尽量用单纯的表达式来代替
避免在 “where” 子句中, 对不同字段进行 “or” 条件查询, 将其拆分成多个单一字段的查询语句效率更高
从数据库结构做起
字段类型的定义时遵循以下规则:
选用字段长度最小
优先使用定长型
尽可能的定义 “NOT NULL”
数值型字段中避免使用 “ZEROFILL”
如果要储存的数据为字符串, 且可能值已知且有限, 优先使用 enum 或 set
索引的优化至关重要(以下如果没有特殊说明, 均指查询密集的情况)
被索引的字段的长度越小, 该索引的效率越高
被索引的字段中, 值的重复越少, 该索引的效率越高
查询语句中, 如果使用了 “group” 子句, 根据其中字段出现的先后顺序建立多字段索引
查询语句中, 如果使用了 “distinct”, 根据其中字段出现的先后顺序建立多字段索引
“where” 子句中, 出现对同一表中多个不同字段的 “and” 条件时, 按照字段出现的先后顺序建立多字段索引
“where” 子句中, 出现对同一表中多个不同字段的 “or” 条件时, 对重复值最少的字段建立单字段索引
进行 “内/外连接” 查询时, 对 “连接字段” 建立索引
对 “主键” 的 “unique” 索引 毫无意义, 不要使用
被索引字段尽可能的使用 “NOT NULL” 属性
对写入密集型表, 尽量减少索引, 尤其是 “多字段索引” 和 “unique” 索引
以下是 MySQL 优化相关的一些说明：
1、检验 key_buffer_size 参数大小是否合适（适用 MyISAM 表）
key_buffer_size
指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。通过检查状态值Ke…]]>
以下是 MySQL 优化相关的一些说明：
1、检验 key_buffer_size 参数大小是否合适（适用 MyISAM 表）
key_buffer_size 指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads，可以知道 key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）（检查状态值，在查询工具里输入 SHOW STATUS ，执行）。
key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
对于1G内存的机器，如果不使用MyISAM表，推荐值是16M（8-64M）。
案例1：健康状况
key_buffer_size – 402649088 (384M)
key_read_requests – 597579931
key_reads – 56188
案例2：警报状态
key_buffer_size – 16777216 (16M)
key_read_requests – 597579931
key_reads – 53832731
案例1中比例低于1:10000，是健康的情况；案例2中比例达到1:11，警报已经拉响。
2、查询缓存 query_cache_size 设置
从 4.0.1 开始，MySQL 提供了查询缓冲机制。在启用查询缓冲的情况下，MySQL 将 SELECT 语句和查询结果存放在缓冲区中（内存），之后对于同样的 SELECT 查询语句（区分大小写），将直接从缓冲区中读取结果，避免了重复查询的无谓开销。和查询缓存相关的参数包括：Qcache_free_blocks、 Qcache_lowmem_prunes、Qcache_free_memory、Qcache_not_cached、 Qcache_total_blocks、Qcache_queries_in_cache、Qcache_hits、Qcache_inserts。其 中，如果 Qcache_lowmem_prunes 的值很大，说明经常出现缓冲不够的情况（最好保持在零），同时 Qcache_hits 的值非常大，则表明查询缓冲使用非常频繁，此时需要增加缓冲大小 Qcache_hits 的值不大，则表明你的查询重复率很低，这种情况下使用查询缓冲反而会影响效率，那么可以考虑不用查询缓冲。另外，如果 Qcache_free_blocks 的值非常大，则表明缓冲区中碎片很多。
3、table_cache
吴威 (16:59:27):
table_cache
The number of open tables for all threads ？？？？
For more information about the table cache, see section 7.4.8 How MySQL Opens and Closes Tables
table_cache 用于指定表高速缓存的大小。每当 MySQL 访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查运行峰值时间的 Open_tables 和 Opened_tables 状态值，可以决定是否需要调整 table_cache 的值。如果你发现 open_tables 的值等于 table_cache，并且发现 opened_tables 状态值在不断增长，那么你就需要增加 table_cache 参数值了（上述状态值可以使用 SHOW STATUS LIKE ‘Open%tables’ 命令获得）。注意，不能盲目地把 table_cache 参数设置成很大的值，如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。
对于有1G内存的机器，推荐值是128－256。
案例1：该案例来自一个不是特别繁忙的服务器
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
该案例中table_cache似乎设置得太高了。在峰值时间，打开表的数目比table_cache要少得多。
案例2：该案例来自一台开发服务器。
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
虽然open_tables已经等于table_cache，但是相对于服务器运行时间来说，opened_tables的值也非常低。因此，增加table_cache的值应该用处不大。
案例3：该案例来自一个upderperforming的服务器
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
该案例中table_cache设置得太低了。虽然运行时间不到6小时，open_tables达到了最大值，opened_tables的值也非常高。这样就需要增加table_cache的值。
4、Measuring Key Buffer Usage
When you add indexes to your data, it enables MySQL to find data faster. However, ideally you want to have these indexes stored in RAM for maximum speed, and the variable key_buffer_size defines how much RAM MySQL can allocate for index key caching. If MySQL cannot store its indexes in RAM, you will experience serious performance problems. Fortunately, most databases have relatively small key buffer requirements, but you should measure your usage to see what work needs to be done.
To do this, log in to MySQL and type SHOW STATUS LIKE ‘%key_read%’;. That returns all the status fields that describe the hit rate of your key buffer—you should get two rows back: Key_reads and Key_read_requests, which are the number of keys being read from disk and the number of keys being read from the key buffer. From these two numbers you can calculate the percentage of requests being filled from RAM and from disk, using this simple equation:
100 – ((Key_reads / Key_read_requests) x 100)
That is, you divide Key_reads by Key_read_requests, multiply the result by 100 and then subtract the result from 100. For example, if you have Key_reads of 1000 and Key_read_requests of 100000, you divide 1000 by 100000 to get 0.01; then you multiply that by 100 to get 1.0, and subtract that from 100 to get 99. That number is the percentage of key reads being served from RAM, which means 99% of your keys are served from RAM.
Most people should be looking to get more than 95% served from RAM, although the primary exception is if you update or delete rows very often—MySQL can’t cache what keeps changing. If your site is largely read only, this should be around 98%. Lower figures mean you might need to bump up the size of your key buffer.
If you are seeing problems, the next step is to check how much of your current key buffer is being used. Use the SHOW VARIABLES command and look up the value of the key_buffer_size variable. It is probably something like 8388600, which is eight million bytes, or 8MB. Now, use the SHOW STATUS command and look up the value of Key_blocks_used.
You can now determine how much of your key buffer is being used by multiplying Key_blocks_used by 1024, dividing by key_buffer_size, and multiplying by 100. For example, if Key_blocks_used is 8000, you multiply that by 1024 to get 8192000; then you divide that by your key_buffer_size (8388600) to get 0.97656, and finally multiplying that by 100 to get 97.656. Thus, almost 98% of your key buffer is being used.
Now, onto the important part: You have ascertained that you are reading lots of keys from disk, and you also now know that the reason for reading from disk is almost certainly because you do not have enough RAM allocated to the key buffer. A general rule of thumb is to allocate as much RAM to the key buffer as you can, up to a maximum of 25% of system RAM—128MB on a 512MB system is about the ideal for systems that read heavily from keys. Beyond that, you will actually see drastic performance decreases because the system has to use virtual memory for the key buffer.