query_cache_type 0 代表不使用缓冲; 1 代表使用缓冲; 2 代表根据需要使用.

开启QC后,对于频繁更新的表, 使用 SQL_NO_CACHE 屏蔽cache, 如: SELECT SQL_NO_CACHE * FROM test.test001 WHERE …. ;

如果QC类型为2, 在需要cache时, 使用 SQL_CACHE 打开缓存, 如: SELECT SQL_CACHE * FROM test.test001 WHERE … ;

网上摘录了一段说明:

1. 何时cache

a) mysql query cache内容为 select 的结果集, cache 使用完整的 sql 字符串做 key, 并区分大小写，空格等。即两个sql必须完全一致才会导致cache命中。

b) prepared statement永远不会cache到结果，即使参数完全一样。据说在 5.1 之后会得到改善。

c) where条件中如包含了某些函数永远不会被cache, 比如current_date, now等。

d) date 之类的函数如果返回是以小时或天级别的，最好先算出来再传进去。
select * from foo where date1=current_date — 不会被 cache
select * from foo where date1=’2008-12-30′ — 被cache, 正确的做法

e) 太大的result set不会被cache (< query_cache_limit)

2. 何时invalidate

a) 一旦表数据进行任何一行的修改，基于该表相关cache立即全部失效。

b) 为什么不做聪明一点判断修改的是否cache的内容？因为分析cache内容太复杂，服务器需要追求最大的性能。

3. 性能

a) cache 未必所有场合总是会改善性能
当有大量的查询和大量的修改时，cache机制可能会造成性能下降。因为每次修改会导致系统去做cache失效操作，造成不小开销。
另外系统cache的访问由一个单一的全局锁来控制，这时候大量>的查询将被阻塞，直至锁释放。所以不要简单认为设置cache必定会带来性能提升。
b) 大result set不会被cache的开销
太大的result set不会被cache, 但mysql预先不知道result set的长度，所以只能等到reset set在cache添加到临界值 query_cache_limit 之后才会简单的把这个cache 丢弃。这并不是一个高效的操作。如果mysql status中Qcache_not_cached太大的话, 则可对潜在的大结果集的sql显式添加 SQL_NO_CACHE 的控制。
query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache

4. 内存池使用

mysql query cache 使用内存池技术，自己管理内存释放和分配，而不是通过操作系统。内存池使用的基本单位是变长的block, 一个result set的cache通过链表把这些block串起来。因为存放result set的时候并不知道这个resultset最终有多大。block最短长度为 query_cache_min_res_unit, resultset 的最后一个block会执行trim操作。

还有一个比较全的: http://www.surfchen.org/wiki/MySQL优化#Query_Cache
MySQL Query Cache 效率的计算

文件: mysql2sqlite.sh

 1 #!/bin/bash

 2 # MySQL 2 SQLite

 3 if [ "x$1" == "x" ]; then

 4     echo "Usage: $0 <dumpname>"

 5     exit

 6 fi

 7

 8 cat $1 |

 9 grep -v ‘ KEY "‘ |

10 grep -v ‘ UNIQUE KEY "‘ |

11 grep -v ‘ PRIMARY KEY ‘ |

12 sed ‘/^SET/d‘ |

13 sed ‘s/ unsigned / /g‘ |

14 sed ‘s/ auto_increment/ primary key autoincrement/g‘ |

15 sed ‘s/ smallint([0-9]*) / integer /g‘ |

16 sed ‘s/ tinyint([0-9]*) / integer /g‘ |

17 sed ‘s/ int([0-9]*) / integer /g‘ |

18 sed ‘s/ character set [^ ]* / /g‘ |

19 sed ‘s/ enum([^)]*) / varchar(255) /g‘ |

20 sed ‘s/ on update [^,]*//g‘ |

21 sed ‘s/\\r\\n/\\n/g‘ |

22 sed ‘s/\\"/"/g‘ |

23 perl -e ‘local $/;$_=<>;s/,\n\)/\n\)/gs;print "begin;\n";print;print "commit;\n"‘ |

24 perl -pe ‘

25 if (/^(INSERT.+?)\(/) {

26   $a=$1;

27   s/\\‘\’‘/‘\’\’‘/g;

28   s/\\n/\n/g;

29   s/\),\(/\);\n$a\(/g;

30 }

31 ‘ > $1.sql

32 cat $1.sql | sqlite3 $1.db > $1.err

33 ERRORS=cat $1.err | wc -l

34 if [ $ERRORS == 0 ]; then

35   echo "Conversion completed without error. Output file: $1.db"

36   rm $1.sql

37   rm $1.err

38 else

39   echo "There were errors during conversion.  Please review $1.err and $1.sql for details."

40 fi

41 # 来源 http://www.sqlite.org/cvstrac/wiki?p=ConverterTools

转换步骤:

#导出WordPress数据库
user@localhost:~$ mysqldump -u root -p –compatible=ansi –skip-opt wordpress > MyBlog.sql

#转换.sql至SQLite数据库文件
user@localhost:~$ sh mysql2sqlite.sh MyBlog.sql

user@localhost:~$ mv MyBlog.db /srv/httpd/wordpress/wp-content/database/MyBlog.sqlite

注: 这个脚本应急还行,但是布署会成问题(转换的字段类型偏差),建议手工校对表结构,添加索引。最后,在linux上,得把sqlite文件的读写权限赋予httpd用户。

###以 MySQL 5.1.42 为例
#tar xvf mysql-5.1.42.tar.gz
#cd mysql-5.1.42/

#./configure –prefix=/usr/local/mysql51 ### 只定安装目录
–with-embedded-server –enable-assembler –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static ### 静态编译
–without-debug –without-docs –without-man –without-readline ### 舍去不必要的东东
–with-charset=utf8 –with-collation=utf8_general_ci ### 指定编码,建议使用utf8, 默认latin1
–with-extra-charsets=complex ### 添加支持的编码, 根据自己的需求指定
–enable-thread-safe-client ### 线程安全
–enable-local-infile –with-ssl –with-libwrap ### 附加网络安全支持
–with-plugins=innobase,heap ### 支持 Innodb 及内存表
###可以不只定系统平台, 编译程序会自检; 如果指定, Like: –with-system-type=i686-redhat-linux-gnu –with-machine-type=i686-redhat-linux-gnu

#make
#sudo make install

编译MySQL 是很轻松的事, 毕竟没有烦琐的配置测试就可以提升不少性能.

在服务器资源有限,单表数据不是特别多的情况下, 独立表空间明显比共享方式效率更高. 但是MySQL 默认是共享表空间, 现在LD 来演示一下转换方法.

### 备份数据库, mysqldump 参数请根据自个儿情况修改
#mysqldump -uroot -p123456 -A –opt > backup.sql

### 停止服务器
#sudo /etc/rc.d/mysqld stop

### 清空数据
#sudo rm -rf /var/mysql/data/*

### 重新生成表结构, 修改权限
#sudo mysql_install_db
#sudo chown mysql:mysql -R /var/mysql/data/

### 关键: 修改配置
#sudo vim /etc/mysql/my.cnf
### [mysqld] 段添加 innodb_file_per_table

### 启动MySQL, 修改数据库用户授权
#sudo /etc/rc.d/mysqld start
#mysqladmin -uroot password ’123456′

### 导回数据
#mysql -uroot -p123456 < backup.sql

OK 大功告成! [mysqld] 有个很有用的配置项 memlock :使MySQL 不写入Swap. 可惜只有在运行MySQL 的用户具有root 权限才行.

Query Cache 在以内容为主的需求下表现很不错, 但业务逻辑一复杂就拖后腿,郁闷ing, set global query_cache_size = 0; 可以运行时关闭Query Cache.

完成升级,包括:

1. 保留原数据;
2. 替换所有存储过程, 函数, 触发器, 视图;
3. 升成必要数据, 插入配置数据;

把过程理顺一下:

1. 导出新数据库A,B,C 的结构;
2. 倒出新数据库A,B,C的存储过程,视图;
3. 单独导出新数据库A,B,C 的触发器;
4. 只导出旧数据库A,B,C 的数据;
5. 重建A,B,C 结构, 导入旧数据(可以用VIM适当调整数据), 导入存储过程,视图,函数;
6. 导入A,B,C 的触发器;
7. 升成必要的数据(python 脚本+存储过程 的方案不错!);

把基本代码写一下, 根据不同情况修改:

3.1 导出表结构
mysqldump -uroot -p’123456′ –default-character-set=utf8 –add-drop-database –add-drop-table –opt -l –no-data -B A B C | sed ‘s/AUTO_INCREMENT=[0-9]*\s//g’ > structure.sql
最后的sed 可以把auto_increment 去除, 为什么? 不多说.

3.2 导出数据
mysqldump -uroot -p’123456′ -c –no-create-db –no-create-info -B A B C > data.sql
如果数据库编码不同, 不能加 –skip-opt

3.3 导出存储过程/函数
SELECT * FROM mysql.proc WHERE db in(‘A’,'B’,'C’);

3.4 导出触发器
mysqldump -uwgz -p’123456′ –default-character-set=utf8 –skip-opt -l –no-create-db –no-create-info –no-data –trigger -B A B C > trigger.sql

3.5 删除触发器
drop trigger /*!50032 if exists */ `A`.`XXOO`;
…… 这里可以改进, 以后有空再说吧.

3.6 建立表结构, 倒入旧数据, 导入存储过程,函数,触发器;

3.7 生成必要的数据
存储过程 + Python 脚本

后记: 本想详写, 但成熟的DBA 一定会有一套自己的备份、还原、升级脚本, 这里只点个意思, 仅此而已.

 1 DELIMITER $$
 2
 3 DROP PROCEDURE IF EXISTS `testMERGE`.`unionSelect`$$
 4 CREATE PROCEDURE `testMERGE`.`unionSelect` (IN startTime CHAR(16), IN endTime CHAR(16))
 5 BEGIN
 6         /* 表test1结果集的总数，结果集开始ID， 结束ID */
 7         DECLARE t1_count BIGINT DEFAULT 0;    
 8         DECLARE t1_startId BIGINT DEFAULT 0;  
 9         DECLARE t1_endId BIGINT DEFAULT 0;            
10         DECLARE t2_count BIGINT DEFAULT 0;
11         DECLARE t2_startId BIGINT DEFAULT 0;  
12         DECLARE t2_endId BIGINT DEFAULT 0;
13
14         /* 先确定两个结果集的开始、结束ID，判断小集合; */
15         SELECT object_id INTO t1_startId FROM t1 WHERE date_format(updated, ‘%Y-%m-%d’) >= startTime ORDER BY object_id LIMIT 1;
16         SELECT object_id INTO t1_endId FROM t1 WHERE date_format(updated, ‘%Y-%m-%d’) <= endTime ORDER BY object_id DESC LIMIT 1;
17         SET t1_count = t1_endId – t1_startId;
18
19         SELECT object_id INTO t2_startId FROM t2 WHERE date_format(updated, ‘%Y-%m-%d’) >= startTime ORDER BY object_id LIMIT 1;
20         SELECT object_id INTO t2_endId FROM t2 WHERE date_format(updated, ‘%Y-%m-%d’) <= endTime ORDER BY object_id DESC LIMIT 1;
21         SET t2_count = t2_endId – t2_startId;
22
23         /* 小集合驱动大集合;  利用主键object_id作为搜索条件！ */
24         IF t1_count < t2_count THEN
25                 SELECT * FROM t1 WHERE object_id BETWEEN t1_startId AND (t1_endId+1)
26                         UNION ALL SELECT * FROM t2 WHERE object_id BETWEEN t2_startId AND (t2_endId+1)
27                         ORDER BY updated DESC LIMIT 0,50;
28         ELSE
29                 SELECT * FROM t2 WHERE object_id BETWEEN t2_startId AND (t2_endId+1)
30                         UNION ALL SELECT * FROM t1 WHERE object_id BETWEEN t1_startId AND (t1_endId+1)
31                         ORDER BY updated DESC LIMIT 0,50;
32         END IF;
33
34 END$$
35
36 DELIMITER ;

mysql> call unionSelect(’2009-10-01′, ’2009-10-31′);
 ——->
Query OK, 0 rows affected (0.97 sec)
多次执行，执行时间为维持在1s左右; 执行时间是原来的一半不到;

LD不是DBA，不过开发中消耗资源比较大的SELECT语句，尽量使用索引，尤其是唯一索引。

LD使用的MySQL是ArchLinux软件库中的，版本5.1.39, 配置文件默认，不做任何内存参数优化(因为使用的数据是真实的，而实际服务器上，运维也使用默认设置);

这两个表2个月前因为表字段的不同，执行一个union all的select语句要 260s 之久; 经过一番优化，已经缩短为2~3s, 但随着数据的增长，执行时间也在增加。LD一直在找解决方案，这么少的数据，还没达到100W，如果不能从SQL优化角度着手，只能从Linux系统和MySQL服务的配置想办法了。 废话不多说，Let’s Go。

一、原数据在InnoDB上的表现
1.1 第一张表 t1 , InnoDB 存储引擎, 50W条数据;
mysql> show create table t1;
+————+——————————-+
| Table      | Create Table                  |
+————+——————————-+
| t1         | CREATE TABLE `t1` (
  `object_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `content` TEXT NOT NULL COMMENT ‘内容’,
  `updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘更新时间’,
  PRIMARY KEY (`object_id`)
 ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT=‘测试表1′                                 |
+————+——————————-+
mysql> SELECT count(*) FROM t1;
+———-+
| count(*) |
+———-+
|   543360 |
+———-+
1 row in set (3.29 sec)

1.2第二张表 t2 , InnoDB 存储引擎, 12W条数据;
mysql> show create table t2;
+————+——————————-+
| Table      | Create Table                  |
+————+——————————-+
| t2         | CREATE TABLE `t2` (
  `object_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `content` TEXT NOT NULL COMMENT ‘内容’,
  `updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘更新时间’,
  PRIMARY KEY (`object_id`)
 ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT=‘测试表1′                                 |
+————+——————————-+
mysql> SELECT count(*) FROM t2;
+———-+
| count(*) |
+———-+
|   129315 |
+———-+
1 row in set (0.64 sec)

1.3对两张表进行UNION之后的结果
mysql> SELECT count(*) AS t2_sum FROM t2 WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ ;
+——–+
| t2_sum |
+——–+
|  56926 |
+——–+
1 row in set (0.44 sec)
mysql> SELECT count(*) AS t1_sum FROM t1 WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ ;
+——–+
| t1_sum |
+——–+
| 234110 |
+——–+
1 row in set (1.82 sec)
mysql> SELECT * FROM t2 WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ UNION ALL SELECT * FROM t1 WHERE updated  BETWEEN ’2009-10-01′ AND ’2009-10-31′ ORDER BY updated DESC LIMIT 0,50;
+———–+———+
|    …    略  …   |
+———–+———+
50 rows in set (3.42 sec)
# 多执行几次，时间在2.6 ~ 3.5 之间徘徊

二、把表类型改为MyISAM，再执行Select union
2.1修改数据表类型
mysql> ALTER TABLE t1 type = MyISAM;
Query OK, 543360 rows affected, 1 warning (4.68 sec)
Records: 543360  Duplicates: 0  Warnings: 0
mysql> ALTER TABLE t2 type = MyISAM;
Query OK, 129315 rows affected, 1 warning (1.10 sec)
Records: 129315  Duplicates: 0  Warnings: 0

2.2 执行SELECT UNION
mysql> SELECT * FROM t2 WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ UNION ALL SELECT * FROM t1 WHERE updated  BETWEEN ’2009-10-01′ AND ’2009-10-31′ ORDER BY updated DESC LIMIT 0,50;
+———–+———+
|    …    略  …   |
+———–+———+
50 rows in set (2.11 sec)
# 多执行几次，时间在2.0 ~ 2.2 之间徘徊

三、使用MERGE合并数据表
3.1创建MERGE数据引擎的表 t3_merge
mysql> CREATE TABLE `t3_merge` (
    -> `object_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
    -> `content` TEXT NOT NULL COMMENT ‘内容’,
    -> `updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘更新时间’,
    -> PRIMARY KEY (`object_id`)
    -> ) ENGINE=MERGE DEFAULT CHARSET=utf8 COMMENT=‘测试MERGE表3′                                

3.2执行SELECT UNION
mysql> SELECT * FROM t3_merge WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ ORDER BY updated DESC LIMIT 0,50;
+———–+———+
|    …    略  …   |
+———–+———+
50 rows in set (2.37 sec)
# 多执行几次，时间在1.62 ~ 1.78 之间徘徊

四、测试视图性能
mysql> CREATE VIEW t4_view AS SELECT object_id, content, updated FROM t2 UNION ALL SELECT object_id, content, updated FROM t1;
Query OK, 0 rows affected (0.10 sec)
mysql> SELECT * FROM t4_view WHERE updated BETWEEN ’2009-10-01′ AND ’2009-10-31′ ORDER BY updated DESC LIMIT 0,50;
+———–+———+
|    …    略  …   |
+———–+———+
50 rows in set (4.22 sec)
# 多执行几次，时间在3.3 ~ 3.5 之间徘徊

五、结论

仅从最终平均执行时间上看，同时查询两张表的数据，merge胜出。 然而为了使用事务，真实数据表使用的是InnoDB，和第一步相同,而MERGE只支持MyISAM的联合。在这种情况中，如果数据表使用MyISAM，配合MERGE还是可取的一种方式(这里不说优化，因为是否真的优化还得再考量);

很多人认为MySQL会对视图有所优化，但实际使用中，你会发现：复杂的情况下使用视图，会托慢整个系统; 不如自己手工优化SQL语句，这时SQL语句也许会很复杂，但省下的性能开销，还是值得的。

1 SELECT id,name,created,action FROM tbl_jobs ORDER BY created DESC, id LIMIT 15;

如上例,直接在’order by’接第二、第三条件即可，很方便。(很久之前LD还考虑过子查询，昏.)

安装完连接库，直接调用就是，剩下的简单，就和其他语言操作数据库的形式相差无几.下面给出一个例子, 想了解更多，请在py终端打入help

#!/usr/bin/env python
# -*-coding:UTF-8-*-
import MySQLdb

conn = MySQLdb.Connection(db_host, db_user, db_passwd, db_name)
cur = conn.cursor()

# 执行SQL语句
cur.execute('SET NAMES utf8')
conn.commit()

# 查询
sql = "SELECT COUNT(*) FROM tbl_test"
cur.execute(sql)
row = cur.fetchone()

# 执行存储过程
cur.callproc('CALL testPro()')
conn.commit()

cur.close()

# FILE END.

那么，怎么才能保证在存储过程中正确的回滚呢？让我们先来看个例子：

CREATE TABLE `test` (`id` int(11) NOT NULL AUTO_INCREMENT,
	`content` varchar(100), PRIMARY KEY (`id`) );

DELIMITER $$
DROP PROCEDURE IF EXISTS  test_sp1 $$
CREATE PROCEDURE test_sp1( )
    BEGIN
        START TRANSACTION;
			INSERT INTO test VALUES(NULL, 'test sql 001');   /* 第一条 insert 能执行 */
			INSERT INTO test VALUES('1', 'test sql 002');  /* 第二条 insert，不能执行 */ 

        IF @@error_count = 0 THEN
            COMMIT;
        ELSE
            ROLLBACK;
        END IF;  

    END$$
DELIMITER ;

我们在MySQL客户端执行 CALL test_sp1(); 之后会发现，存储过程中第一条insert成功的执行了，而第二条执行没有执行，但是注意！ 这里发生了错误，而作为判断的 @@error_count 没有反应, ROLLBACK 不能回滚！

在我上一篇文章 《执行一半的存储过程 – MySQL邯郸学步》中存储过程执行了一半， 而很不幸的，这里的 test_sp1() 也执行了一般，就好比我们PHP、JAVA、C++程序遇到错误一样，抛出error, 然后停止执行。

之前使用PDO，在处理事务时，使用SQLException捕获SQL错误，然后处理； 按照这个推论，我们必须在MySQL存储过程中捕获SQL错误，最后判断是回滚(ROLLBACK)还是提交(COMMIT)。 所以存储过程可以改为：

DELIMITER $$
DROP PROCEDURE IF EXISTS  test_sp1 $$
CREATE PROCEDURE test_sp1( )
    BEGIN
	DECLARE t_error INTEGER DEFAULT 0;
    DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET t_error=1;

		START TRANSACTION;
			INSERT INTO test VALUES(NULL, 'test sql 001');   /* 第一条 insert 能执行 */
			INSERT INTO test VALUES('1', 'test sql 002');  /* 第二条 insert，不能执行 */ 

        F txn_error = 1 THEN
			ROLLBACK;
		ELSE
			COMMIT;
		END IF;

    END$$
DELIMITER ;

第二个例子中，我们为test_sp1() 定义了一个 SQLEXCEPTION 参数 t_error， 在遇到SQL错误时，继续执行(CONTINUE); 如果执行状态没有错误，则提交，反之回滚！

如果存储过程A包含B， 那么最好只在A中定义事务； 记住，保证事务的原子性。

下面是我摘抄的，值得挤公车时慢慢品味：

1，保持事务短小
2，尽量避免事务中rollback
3，尽量避免savepoint
4，默认情况下，依赖于悲观锁
5，为吞吐量要求苛刻的事务考虑乐观锁
6，显示声明打开事务
7，锁的行越少越好，锁的时间越短越好