mysql

InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与ORACLE不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！ 在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面我们通过一些实际例子，来加以说明。 （1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。 下面的例子中，开始tab_no_index表没有索引： mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb; Query OK, 0 rows affected (0.15 sec) mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4'); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 InnoDB存储引擎的表在不使用索引时使用表锁例子 session_1 session_2 mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_no_index where id = 1 ; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0....

InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等 高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务 支持已经外部键等高级数据库功能。 MyIASM是IASM表的新版本，有如下扩展： 二进制层次的可移植性。 NULL列索引。 对变长行比ISAM表有更少的碎片。 支持大文件。 更好的索引压缩。 更好的键吗统计分布。 更好和更快的auto_increment处理。 每个MyISAM表最大索引数是64。 这可以通过重新编译来改变。每个索引最大的列数是16个。 以下是一些细节和具体实现的差别： 1.InnoDB不支持FULLTEXT类型的索引。 2.InnoDB 中不保存表的具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的操作是一样的。 3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。 4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。 5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。 另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%” 任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。 http://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html

查看 MySQL 語法 詳細執行時間 與 CPU/記憶體使用量: MySQL Query Profiler MySQL 的 SQL 語法調整主要都是使用 EXPLAIN, 但是這個並沒辦法知道詳細的 Ram(Memory)/CPU 等使用量. 於 MySQL 5.0.37 以上開始支援 MySQL Query Profiler, 可以查詢到此 SQL 會執行多少時間, 並看出 CPU/Memory 使用量, 執行過程中 System lock, Table lock 花多少時間等等. MySQL Query Profile 詳細介紹可見: Using the New MySQL Query Profiler (2007.04.05 發表) 效能分析主要分下述三種(轉載自上篇): Bottleneck analysis - focuses on answering the questions: What is my database server waiting on; what is a user connection waiting on; what is a piece of SQL code waiting on?...

If you’re using NGinx spawn-cgi or FPM with PHP and calling mysql_pconnect, you are likely going to experience frequent database crashes and “Too many connections” errors. This took a while to trace, but once you understand the issue, it all makes sense. mysql_pconnect opens a “persistent” connection to the database. From the documentation: “the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect())....

This step by step tutorial is everything you need to install MySQL 5.1 (from source) on a virgin FreeBSD 4.x - 7.x machine. Step 1: Install wget cd /usr/ports/ftp/wget make make install Step 2: Download MySQL 5.1 source code mkdir /usr/tmp cd /usr/tmp wget "http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.24-rc.tar.gz/from/http://mysql.he.net/" tar xvzf mysql-5.1.24-rc.tar.gz Step 3: Create mysql user adduser Follow the prompts to create a mysql user and mysql group with a default directory of /usr/local/mysql...

在做sql查询的时候，应该想到explain，这样用来对sql的执行效率进行分析。 mysql explain的详解 explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 使用方法，在select语句前加上explain就可以了： 如：explain select surname,first_name form a,b where a.id=b.id 分析结果形式如下： table type possible_keys key key_len ref rows extra a range id first_name First_name 9 NULL 23112 Using where　Using temporary　Using filesort b ref id　first_name id 4 id 2 Using where EXPLAIN列的解释： table：显示这一行的数据是关于哪张表的 type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句 key：实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用 USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引 key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好 ref：显示索引的哪一列被使用了，如果可能的话，是一个常数 rows：MYSQL认为必须检查的用来返回请求数据的行数 Extra：关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢 extra列返回的描述的意义 Distinct:一旦MYSQL找到了与行相联合匹配的行，就不再搜索了 Not exists: MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了 Range checked for each Record（index map:#）:没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一 Using filesort: 看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行 Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候 Using temporary 看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上 Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序） system 表只有一行：system表。这是const连接类型的特殊情况 const:表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待 eq_ref:在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用 ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好 range:这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况 index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据） ALL:这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免

杜比环绕声 http://blog.chinaunix.net/u/12258/showart_292352.html 一、从mysql的启动脚本说起 配置mysql的时候，如果需要启动运行 mysql server，按照 mysql 手册上的说明，需要在 /etc/rc.conf 中，添加一条信息： mysql_enable="YES" 这样在重新启动系统的时候，就可以自动运行 mysqlserver. 如果需要运行时，停止 mysqlserver 或者重新启动 mysqlserver，可以使用下面的命令： 停止mysqlserver: shell>/usr/local/etc/rc.d/mysql-server stop 重新启动mysqlserver: shell>/usr/local/etc/rc.d/mysql-server restart 其实无论是mysqlserver还是apache等系统服务，都可以利用上面提到的参数“stop“，”restart“等进行程序维护 这属于FreeBSD系统rc脚本系统的具体应用。 FreeBSD的rc脚本系统在服务程序的管理上，主要是体现在 /etc/rc.d 和 /usr/local/etc/rc.d 这两个目录下的可执行脚本，系统级别的服务程序的脚本大都安装在 /etc/rc.d目录下，而用户级别的服务程序的脚本都安装在 /usr/local/etc/rc.d 目录下。如 mysql server 在安装的时候会在 /usr/local/etc/rc.d目录下安装一个 mysql-server 的脚本文件。 服务程序的管理，其实运行的就是对应的脚本文件。如上面举例的停止服务，重新启动服务，运行的都是mysql-server脚本。 二、mysql-server 启动脚本的说明 下面的脚本代码是freebsd 6.2中mysqlserver 5.0的启动脚本。具体的功能在脚本代码中注释！ #!/bin/sh $FreeBSD: ports/databases/mysql50-server/files/mysql-server.sh.in,v 1.3 2006/03/07 16:25:00 ale Exp $ #下面这部分文本描述了可以在rc.conf中设置、添加的启动条目，用来控制mysqlserver启动的一些具体细节。 PROVIDE: mysql REQUIRE: LOGIN KEYWORD: shutdown Add the following line to /etc/rc.conf to enable mysql: mysql_enable (bool): Set to “NO” by default....

freebsd 7.0 amd64 mysqlslap -a --concurrency=5,10,20,50,150 --number-of-queries 100000 --debug-info Benchmark Average number of seconds to run all queries: 766.733 seconds Minimum number of seconds to run all queries: 766.733 seconds Maximum number of seconds to run all queries: 766.733 seconds Number of clients running queries: 5 Average number of queries per client: 20000 Benchmark Average number of seconds to run all queries: 820.050 seconds Minimum number of seconds to run all queries: 820....

转自 http://yueliangdao0608.blog.51cto.com/397025/81602 MySQL5.1地的确提供了好多有力的工具来帮助我们DBA进行数据库管理。 现在看一下这个压力测试工具mysqlslap. 关于他的选项手册上以及–help介绍的很详细。 我解释一下一些常用的选项。 这里要注意的几个选项： --concurrency代表并发数量，多个可以用逗号隔开，当然你也可以用自己的分隔符隔开，这个时候要用到--delimiter开关。 --engines代表要测试的引擎，可以有多个，用分隔符隔开。 --iterations代表要运行这些测试多少次。 --auto-generate-sql 代表用系统自己生成的SQL脚本来测试。 --auto-generate-sql-load-type 代表要测试的是读还是写还是两者混合的（read,write,update,mixed） --number-of-queries 代表总共要运行多少次查询。每个客户运行的查询数量可以用查询总数/并发数来计算。比如倒数第二个结果2=200/100。 --debug-info 代表要额外输出CPU以及内存的相关信息。 --number-int-cols 代表示例表中的INTEGER类型的属性有几个。 --number-char-cols 意思同上。 --create-schema 代表自己定义的模式（在MySQL中也就是库）。 --query 代表自己的SQL脚本。 --only-print 如果只想打印看看SQL语句是什么，可以用这个选项。 现在来看一些测试的例子。 1、用自带的SQL脚本来测试。 MySQL版本为5.1.23 [root@localhost ~]# mysqlslap --defaults-file=/usr/local/mysql-maria/my.cnf --concurrency=50,100,200 --iterations=1 --number-int-cols=4 --number-char-cols=35 --auto-generate-sql --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=mixed --engine=myisam,innodb --number-of-queries=200 --debug-info -uroot -p1 -S/tmp/mysql_3310.sock Benchmark Running for engine myisam Average number of seconds to run all queries: 0.063 seconds Minimum number of seconds to run all queries: 0....

系統：FreeBSD 7.1-RELEASE MySQL：5.1.30 Sphinx：0.9.8.1 mysql51-server.diff diff -Nur /usr/ports/databases/mysql51-server/Makefile mysql51-server/Makefile — /usr/ports/databases/mysql51-server/Makefile 2008-07-27 09:56:19.000000000 +0100 +++ mysql51-server/Makefile 2008-08-06 16:20:51.000000000 +0100 @@ -60,6 +60,16 @@ CONFIGURE_ARGS+=–with-collation=${WITH_COLLATION} .endif +# Sphinx Engine +.if defined(WITH_SPHINXSE) +SPHINX_PORT?= textproc/sphinxsearch +SPHINX_WRKSRC= cd ${PORTSDIR}/${SPHINX_PORT} && ${MAKE} -V WRKSRC + +EXTRACT_DEPENDS+= ${NONEXISTENT}:${PORTSDIR}/${SPHINX_PORT}:extract +RUN_DEPENDS+= searchd:${PORTSDIR}/${SPHINX_PORT} +USE_AUTOTOOLS+= autoconf:262 automake:110 +.endif + .include .if ${ARCH} == “i386″ @@ -124,8 +134,14 @@ @${ECHO} “ BUILD_STATIC=yes Build a static version of mysqld.” @${ECHO} “ (use it if you need even more speed)....

我们的项目中有好多不等于的情况。今天写这篇文章简单的分析一下怎么个优化法。 这里的分表逻辑是根据t_group表的user_name组的个数来分的。 因为这种情况单独user_name字段上的索引就属于烂索引。起不了啥名明显的效果。 1、试验PROCEDURE. DELIMITER $$ DROP PROCEDURE `t_girl`.`sp_split_table`$$ CREATE PROCEDURE `t_girl`.`sp_split_table`() BEGIN declare done int default 0; declare v_user_name varchar(20) default ''; declare v_table_name varchar(64) default ''; -- Get all users' name. declare cur1 cursor for select user_name from t_group group by user_name; -- Deal with error or warnings. declare continue handler for 1329 set done = 1; -- Open cursor. open cur1; while done <> 1 do fetch cur1 into v_user_name; if not done then -- Get table name....

最近发现用户注册老是出错,不确定问题所在,不知道是不是SQL CACHE引起的, 原理 QueryCache(下面简称QC)是根据SQL语句来cache的。一个SQL查询如果以select开头，那么MySQL服务器将尝试对其使用 QC。每个Cache都是以SQL文本作为key来存的。在应用QC之前，SQL文本不会被作任何处理。也就是说，两个SQL语句，只要相差哪怕是一个字符（例如大小写不一样；多一个空格等），那么这两个SQL将使用不同的一个CACHE。 不过SQL文本有可能会被客户端做一些处理。例如在官方的命令行客户端里，在发送SQL给服务器之前，会做如下处理： 过滤所有注释 去掉SQL文本前后的空格,TAB等字符。注意，是文本前面和后面的。中间的不会被去掉。 下面的三条SQL里，因为SELECT大小写的关系，最后一条和其他两条在QC里肯定是用的不一样的存储位置。而第一条和第二条，区别在于后者有个注释，在不同客户端，会有不一样的结果。所以，保险起见，请尽量不要使用动态的注释。在PHP的mysql扩展里，SQL的注释是不会被去掉的。也就是三条 SQL会被存储在三个不同的缓存里，虽然它们的结果都是一样的。 select * FROM people where name='surfchen'; select * FROM people where /*hey~*/name='surfchen'; SELECT * FROM people where name='surfchen'; 目前只有select语句会被cache，其他类似show,use的语句则不会被cache。 因为QC是如此前端，如此简单的一个缓存系统，所以如果一个表被更新，那么和这个表相关的SQL的所有QC都会被失效。假设一个联合查询里涉及到了表A和表B，如果表A或者表B的其中一个被更新（update或者delete），这个查询的QC将会失效。 也就是说，如果一个表被频繁更新，那么就要考虑清楚究竟是否应该对相关的一些SQL进行QC了。一个被频繁更新的表如果被应用了QC，可能会加重数据库的负担，而不是减轻负担。我一般的做法是默认打开QC，而对一些涉及频繁更新的表的SQL语句加上SQL_NO_CACHE关键词来对其禁用CACHE。这样可以尽可能避免不必要的内存操作，尽可能保持内存的连续性。 那些查询很分散的SQL语句，也不应该使用QC。例如用来查询用户和密码的语句——“select pass from user where name='surfchen'”。这样的语句，在一个系统里，很有可能只在一个用户登陆的时候被使用。每个用户的登陆所用到的查询，都是不一样的SQL 文本，QC在这里就几乎不起作用了，因为缓存的数据几乎是不会被用到的，它们只会在内存里占地方。 存储块 在本节里“存储块”和“block”是同一个意思 QC缓存一个查询结果的时候，一般情况下不是一次性地分配足够多的内存来缓存结果的。而是在查询结果获得的过程中，逐块存储。当一个存储块被填满之后，一个新的存储块将会被创建，并分配内存（allocate）。单个存储块的内存分配大小通过query_cache_min_res_unit参数控制，默认为4KB。最后一个存储块，如果不能被全部利用，那么没使用的内存将会被释放。如果被缓存的结果很大，那么会可能会导致分配内存操作太频繁，系统系能也随之下降；而如果被缓存的结果都很小，那么可能会导致内存碎片过多，这些碎片如果太小，就很有可能不能再被分配使用。 除了查询结果需要存储块之外，每个SQL文本也需要一个存储块，而涉及到的表也需要一个存储块（表的存储块是所有线程共享的，每个表只需要一个存储块）。存储块总数量=查询结果数量*2+涉及的数据库表数量。也就是说，第一个缓存生成的时候，至少需要三个存储块：表信息存储块，SQL文本存储块，查询结果存储块。而第二个查询如果用的是同一个表，那么最少只需要两个存储块：SQL文本存储块，查询结果存储块。 通过观察Qcache_queries_in_cache和Qcache_total_blocks可以知道平均每个缓存结果占用的存储块。它们的比例如果接近1:2，则说明当前的query_cache_min_res_unit参数已经足够大了。如果Qcache_total_blocks比 Qcache_queries_in_cache多很多，则需要增加query_cache_min_res_unit的大小。 Qcache_queries_in_cache*query_cache_min_res_unit（sql文本和表信息所在的block占用的内存很小，可以忽略）如果远远大于query_cache_size-Qcache_free_memory，那么可以尝试减小 query_cache_min_res_unit的值。 调整大小 如果Qcache_lowmem_prunes增长迅速，意味着很多缓存因为内存不够而被释放，而不是因为相关表被更新。尝试加大query_cache_size，尽量使Qcache_lowmem_prunes零增长。 启动参数 show variables like 'query_cache%'可以看到这些信息。 query_cache_limit:如果单个查询结果大于这个值，则不Cache query_cache_size:分配给QC的内存。如果设为0，则相当于禁用QC。要注意QC必须使用大约40KB来存储它的结构，如果设定小于 40KB,则相当于禁用QC。QC存储的最小单位是1024 byte，所以如果你设定了一个不是1024的倍数的值，这个值会被四舍五入到最接近当前值的等于1024的倍数的值。 query_cache_type:0 完全禁止QC，不受SQL语句控制（另外可能要注意的是，即使这里禁用，上面一个参数所设定的内存大小还是会被分配）；1启用QC，可以在SQL语句使用 SQL_NO_CACHE禁用；2可以在SQL语句使用SQL_CACHE启用。 query_cache_min_res_unit:每次给QC结果分配内存的大小 状态 show status like 'Qcache%'可以看到这些信息。 Qcache_free_blocks:当一个表被更新之后，和它相关的cache blocks将被free。但是这个block依然可能存在队列中，除非是在队列的尾部。这些blocks将会被统计到这个值来。可以用FLUSH QUERY CACHE语句来清空free blocks。 Qcache_free_memory:可用内存，如果很小，考虑增加query_cache_size Qcache_hits:自mysql进程启动起，cache的命中数量 Qcache_inserts:自mysql进程启动起，被增加进QC的数量 Qcache_lowmem_prunes:由于内存过少而导致QC被删除的条数。加大query_cache_size，尽可能保持这个值0增长。 Qcache_not_cached:自mysql进程启动起，没有被cache的只读查询数量（包括select,show,use,desc等） Qcache_queries_in_cache:当前被cache的SQL数量 Qcache_total_blocks:在QC中的blocks数。一个query可能被多个blocks存储，而这几个blocks中的最后一个，未用满的内存将会被释放掉。例如一个QC结果要占6KB内存，如果query_cache_min_res_unit是4KB，则最后将会生成3个 blocks，第一个block用来存储sql语句文本，这个不会被统计到query+cache_size里，第二个block为4KB，第三个 block为2KB（先allocate4KB，然后释放多余的2KB）。每个表，当第一个和它有关的SQL查询被CACHE的时候，会使用一个 block来存储表信息。也就是说，block会被用在三处地方：表信息，SQL文本，查询结果。 另外一篇： 如果 MySQL Server 负载比较高，处理非常繁忙的话，可以启动Query Cache 以加速响应时间，启动方法可以在my....

接着昨天没有写完的那个无重复的随即数字的程序，我们展开来讲！既然做这个程序的的目的是为了对买彩票的程序作准备！所以我要把 每次 的结果保存到SQL server 数据库中！我的想法是首先运行100万次摇奖的程序后，将这100万条数据存放到数据库中,然后用SQL语句选择出重复次数最多的一组数据，这个就是我的想法！大家仅仅是参考，千万不要模仿呀：）前面我们已经说过如何生成不重复的随即数，我们就利用那个函数来生成一组数据，如此重复100万次！经过3个小时的运算以后，我们得到了一组巨大的记录，下面我们来看看 如何得到 重复次数最多的一组号码呢？我们以前曾经讲过，使用distinct 可以使我们得到一个不重复的记录集(select distinct * from table1)，那么怎么得到有重复的记录集呢,显然 简单的使用关键字是不可能实现的了，豆腐最终确定使用Having子句来实现这样的功能,SQL 语句如下,select * from table1 having count()>1 这样我们就得到了一个所有记录重复次数超过一次的记录集，我们利用如下语句 select count() ccount from table1 group by a1,a2,a3,a4,a5,a6,a7 having count(*)>! order by ccount desc 这样得到的第一个记录就是出现重复次数最多的那组数字。 /* 豆腐制作 都是精品 http://www.asp888.net 豆腐技术站 如转载 请保留完整版权信息 */

同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力 严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月 MySQL使用是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。 安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的 配制文件了。一般的情况下，my-medium.cnf这个配制文件就能满足我们的大多需要； 一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了 使用mysqladmin variables extended-status –u root –p 可以看到目前的参数 有３个配置参数是最重要的，即key_buffer_size,query_cache_size,table_cache 1.key_buffer_size key_buffer_size只对MyISAM表起作用 key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。一般我们设为16M,实 际上稍微大一点的站点　这个数字是远远不够的，通过检查状态值Key_read_requests和 Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可 能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）。 或者如 果你装了phpmyadmin 可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql，以下的状态值都是本人 通过phpmyadmin获得的 实例分析: 这个服务器已经运行了20天 key_buffer_size – 128M key_read_requests – 650759289 key_reads - 79112 比例接近1:8000 健康状况非常好 另外一个估计key_buffer_size的办法　把你网站数据库的每个表的索引所占空间大小加起来看看 以此服务器为例:比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大 2.query_cache_size 从4.0.1开始，MySQL提供了查询缓冲机制。使用查询缓冲，MySQL将SELECT语句和查询结果存放在缓冲区中，今 后对于同样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最 多可以达到238%的效率。 通过调节以下几个参数可以知道query_cache_size设置得是否合理 Qcache inserts Qcache hits Qcache lowmem prunes Qcache free blocks Qcache total blocks...

count(distinct a.id) as count 以前还真没这么用过