百里挑一

百里挑一 http://www.admin99.net/index.php linux命令 | seo优化技术 | linux系统管理员指南 --我的学习园地 zh-cn Powered by Bo-blog 2.0.2 sp2 http://www.admin99.net/read.php?462 mysql恢复 real <real@admin99.net> mysql Wed, 20 Jan 2010 10:21:33 +0000 http://www.admin99.net/read.php?462 mysqldump备份
多个数据库
恢复其中的一个
找到该数据库在.sql文件中的位置
grep -n "CREATE DATABASE" mysqldata.20100109.sql |grep -v help_topic
将改数据库的内容拿出来，注意前后可能要增加或减少几行
sed -n '85082,97412p' mysqldata.20100109.sql > views.20100109.sql &
然后导入

多个数据库，恢复其中一个
比如数据库是admin99
tar xzvf mysqldata.tar.gz ./ data/mysqldata/admin99
Tags - mysql ]]> http://www.admin99.net/read.php?452 Mysqldump: Got error: 29: File ./test/test.MYD not found real <real@admin99.net> mysql Fri, 16 Oct 2009 07:01:19 +0000 http://www.admin99.net/read.php?452 检查之后发现报错的文件确实存在，而且没有问题
后得知是mysql打开的文件数太多
查看ulimit -n 发现是默认的1024
于是调整为51200

引用

ulimit -n 51200

然后重启mysql
再执行就正确了
Tags - mysql ]]> http://www.admin99.net/read.php?437 一个超低级错误，关于mysql real <real@admin99.net> mysql Sat, 09 May 2009 07:18:17 +0000 http://www.admin99.net/read.php?437 添加好mysql组和用户
执行
./scripts/mysql_install_db --user=mysql
时报错
scripts/mysql_install_db: line 1: ./bin/my_print_defaults: cannot execute binary file
Neither host 'web' nor 'localhost' could be looked up with
./bin/resolveip
Please configure the 'hostname' command to return a correct hostname.
If you want to solve this at a later stage, restart this script with
the --force option
原来还以为域名解析没配置好什么的
后来才发现，下载的版本不对
操作系统是32位的。下载的这个mysql是64位的.........
换成32位就好了
Tags - mysql ]]> http://www.admin99.net/read.php?435 mysql加载tcmalloc，配置不当可能会耗光内存 real <real@admin99.net> mysql Fri, 08 May 2009 15:23:14 +0000 http://www.admin99.net/read.php?435 服务器配置两颗4核E5410 8G内存 146G sas 15k转速的硬盘
系统为centos 5.2 64位 mysql 5.1.32 64位
平均每秒约1w次查询，优化的还不错，性能很好，负载4左右也很稳定
不知道什么原因，内存貌似失控了。内存的使用率，跟配置的完全不是一回事，一般48小时内就能把8G内存耗光，估计4天左右又能把4G的swap空间耗光，用到swap的时候，性能并没有下降。然后，就内存溢出了，挺郁闷。
目前的内存使用情况
free -m
total used free shared buffers cached
Mem: 7982 6999 983 0 237 955
-/+ buffers/cache: 5806 2175
Swap: 4094 6 4087
预计3天以后就能把物理内存和swap都能耗光，然后溢出
把tcmalloc去掉之后，重启了mysql。观察了约30小时，确认问题已解决
目前的内存使用情况
Mem: 8174224k total, 6755448k used, 1418776k free, 340204k buffers
Swap: 4192956k total, 7008k used, 4185948k free, 1285500k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15213 mysql 15 0 5873m 4.8g 5652 S 212 61.3 1668:10 mysqld
这个问题可以描述为这样，这是我目前的推测
tcmalloc在为线程分配内存的时候，会比glibc之类的malloc分配的稍微多些，它倾向于稳定，避免大起大落。因为这台服务器非常繁忙(平均每秒约1w次)，而我之前配置的thread_cache_size 偏小，查看status之后发现，threads_created 值非常高，也就是说，mysql线程的重用程度非常低。而每创建一个线程，tcmalloc都会多分配一些内存。线程销毁的时候，可能这稍稍多出来的一部分内存没有收回，也就是泄露了。时间长了，在我这台服务器上，大约4天，就能把8G物理内存加4G swap耗光，造成kernel没有新内存可以用，进而kernel溢出，杀掉占用内存最多的mysqld

现在引伸出来三个新问题，有兴趣的朋友可以琢磨一下
1. 如果thread_cache_size 配置非常大，mysql线程重用程度非常高，应该是可以把内存溢出的过程拖的非常长，比如之前是4天，可能现在400天也不会溢出
2.之前看过有人编译nginx的时候也用tcmalloc ，nginx的线程创建和销毁更为频繁，我怀疑会不会它造成溢出的可能性更高？不过话说回来，一般情况下，一个nginx进程占用的内存很小的，只有4~20M，一般服务器也就开几个这样的进程。所以，貌似它能出问题的机会很小
3.我这次在mysql中用tcmalloc，是用preload的方式。不知道用源码，编译的时候把tcmalloc编译进去，是否还会出现这个问题
有机会再测试上面三个问题
Tags - mysql ]]> http://www.admin99.net/read.php?434 转载根据status信息对MySQL服务器进行优化 real <real@admin99.net> mysql Thu, 07 May 2009 05:32:21 +0000 http://www.admin99.net/read.php?434
mysql> show global status;

可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：

mysql> show variables;

一、慢查询

mysql> show variables like '%slow%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
| slow_launch_time | 2 |
+------------------+-------+

mysql> show global status like '%slow%';
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| Slow_launch_threads | 0 |
| Slow_queries | 4148 |
+---------------------+-------+

配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给MySQL打补丁：http://www.percona.com/docs/wiki/release:start，记得找对应的版本。

打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。

二、连接数

经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小：

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+

这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数：

mysql> show global status like 'Max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 245 |
+----------------------+-------+

MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是：

Max_used_connections / max_connections * 100% ≈ 85%

最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。

三、Key_buffer_size

key_buffer_size是对MyISAM表性能影响最大的一个参数，下面一台以MyISAM为主要存储引擎服务器的配置：

mysql> show variables like 'key_buffer_size';
+-----------------+------------+
| Variable_name | Value |
+-----------------+------------+
| key_buffer_size | 536870912 |
+-----------------+------------+

分配了512MB内存给key_buffer_size，我们再看一下key_buffer_size的使用情况：

mysql> show global status like 'key_read%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
+------------------------+-------------+

一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：

key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%

比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT 了，key_cache_miss_rate在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在 0.01%以下的话，key_buffer_size分配的过多，可以适当减少。

MySQL服务器还提供了key_blocks_*参数：

mysql> show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

四、临时表

mysql> show global status like 'created_tmp%';
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+-------------------------+---------+

每次创建临时表，Created_tmp_tables增加，如果是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数，比较理想的配置是：

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%

比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 1.20%，应该相当好了。我们再看一下MySQL服务器对临时表的配置：

mysql> show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+---------------------+-----------+

只有256MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。

五、Open Table情况

mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 919 |
| Opened_tables | 1951 |
+---------------+-------+

Open_tables表示打开表的数量，Opened_tables表示打开过的表数量，如果Opened_tables数量过大，说明配置中 table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小，我们查询一下服务器table_cache值：

mysql> show variables like 'table_cache';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| table_cache | 2048 |
+---------------+-------+

比较合适的值为：

Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% <= 95%
六、进程使用情况

mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 46 |
| Threads_connected | 2 |
| Threads_created | 570 |
| Threads_running | 1 |
+-------------------+-------+

如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（前提是缓存数未达上限）。Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器 thread_cache_size配置：

mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 64 |
+-------------------+-------+

示例中的服务器还是挺健康的。

七、查询缓存(query cache)

mysql> show global status like 'qcache%';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 22756 |
| Qcache_free_memory | 76764704 |
| Qcache_hits | 213028692 |
| Qcache_inserts | 208894227 |
| Qcache_lowmem_prunes | 4010916 |
| Qcache_not_cached | 13385031 |
| Qcache_queries_in_cache | 43560 |
| Qcache_total_blocks | 111212 |
+-------------------------+-----------+

MySQL查询缓存变量解释：

Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory：缓存中的空闲内存。
Qcache_hits：每次查询在缓存中命中时就增大
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks和free_memory可以告诉您属于哪种情况）
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前缓存的查询（和响应）的数量。
Qcache_total_blocks：缓存中块的数量。

我们再查询一下服务器关于query_cache的配置：

mysql> show variables like 'query_cache%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 203423744 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+

各字段的解释：

query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小
query_cache_size：查询缓存大小
query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询
query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。

query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器查询缓存碎片率＝ 20.46％，查询缓存利用率＝ 62.26％，查询缓存命中率＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。

八、排序使用情况

mysql> show global status like 'sort%';
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Sort_merge_passes | 29 |
| Sort_range | 37432840 |
| Sort_rows | 9178691532 |
| Sort_scan | 1860569 |
+-------------------+------------+

Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，等 MySQL 找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上，MySQL 会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，见 How fast can you sort data with MySQL?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙）

另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处，参见：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/

九、文件打开数(open_files)

mysql> show global status like 'open_files';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 1410 |
+---------------+-------+

mysql> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 4590 |
+------------------+-------+

比较合适的设置：Open_files / open_files_limit * 100% <= 75％

十、表锁情况

mysql> show global status like 'table_locks%';
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| Table_locks_immediate | 490206328 |
| Table_locks_waited | 2084912 |
+-----------------------+-----------+

Table_locks_immediate表示立即释放表锁数，Table_locks_waited表示需要等待的表锁数，如果 Table_locks_immediate / Table_locks_waited > 5000，最好采用InnoDB引擎，因为InnoDB是行锁而MyISAM是表锁，对于高并发写入的应用InnoDB效果会好些。示例中的服务器 Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足够了。

十一、表扫描情况

mysql> show global status like 'handler_read%';
+-----------------------+-------------+
| Variable_name | Value |
+-----------------------+-------------+
| Handler_read_first | 5803750 |
| Handler_read_key | 6049319850 |
| Handler_read_next | 94440908210 |
| Handler_read_prev | 34822001724 |
| Handler_read_rnd | 405482605 |
| Handler_read_rnd_next | 18912877839 |
+-----------------------+-------------+

各字段解释参见http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html，调出服务器完成的查询请求次数：

mysql> show global status like 'com_select';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| Com_select | 222693559 |
+---------------+-----------+

计算表扫描率：

表扫描率＝ Handler_read_rnd_next / Com_select

如果表扫描率超过4000，说明进行了太多表扫描，很有可能索引没有建好，增加read_buffer_size值会有一些好处，但最好不要超过8MB。
Tags - mysql ]]> http://www.admin99.net/read.php?424 使用tcmalloc提升mysql在高负载下的性能和稳定性 real <real@admin99.net> mysql Wed, 22 Apr 2009 01:51:30 +0000 http://www.admin99.net/read.php?424 有台mysql服务器，每秒约5000次查询。负载比较高。准备试一下tcmalloc。
安装过程
1。如果是64位的系统，要先安装libunwind，32位系统不要安装。另外要注意libunwind的版本，用0.99-beta版的，比这个新比这个旧都不好

引用

wget http://ftp.twaren.net/Unix/NonGNU/libunwind/libunwind-0.99-beta.tar.gz
tar zxvf libunwind-0.99-beta.tar.gz
cd libunwind-0.99-beta
./configure
make
make install

2。安装google-perftools

引用

wget http://google-perftools.googlecode.com/files/google-perftools-1.2.tar.gz
tar zxvf google-perftools-1.2.tar.gz
cd google-perftools-1.2
./configure
make
make install

3。修改mysql启动脚本

引用

vi /usr/local/mysql/bin/mysqld_safe

在最上面添加

引用

export LD_PRELOAD=/usr/local/lib/libtcmalloc.so

重启mysql
4。检查有没有生效

引用

lsof -n | grep tcmalloc

如果有使用到/usr/local/lib/libtcmalloc.so.0.0.0 就已生效

ps： 64位系统下64位的mysql在使用本文的时候恐怕要加个链接才能用
ln -s /usr/local/lib/libunwind.so.7 /usr/lib64/
Tags - mysql , google ]]> http://www.admin99.net/read.php?423 开启mysql的常规查询日志 real <real@admin99.net> mysql Tue, 21 Apr 2009 06:52:30 +0000 http://www.admin99.net/read.php?423 开启的办法很简单
在my.cnf中，加入

引用

log=/backup/logs/mysql/access.log

如果 /backup/logs/mysql 这个目录对于mysql用户可写，那么重启mysql的时候会自动生成access.log这个文件。如果该目录对于mysql不可写，那么手工创建这个目录，并加入mysql用户的写权限。

以上方法在5.1版本以前可用，对于5.2及以后的版本，据说需要在my.cnf中加入两个参数(尚未测试)

引用

log=/backup/logs/mysql/access.log
log-output=FILE

对于生产服务器，这个日志文件的增长速度是很惊人的，一般情况下建议不要打开这个选项。
如果必须打开此选项，那么，对access.log一定要做一些处理，比如轮询和自动清理等
下面是一个简单的轮询日志的命令集，设置cronteb每晚23:59分执行一下就好了

引用

#!/bin/bash
mv /backup/logs/mysql/access.log /backup/logs/mysql/access.log.$(date +%Y%m%d)
touch /backup/logs/mysql/access.log
chown mysql:mysql /backup/logs/mysql/access.log
/usr/local/mysql/bin/mysqladmin -pyourmysqlpassword flush-logs
rm -rf /backup/logs/mysql/access.log.$(date +%Y%m%d -d '15 days ago')

Tags - mysql ]]> http://www.admin99.net/read.php?403 mysql 卡死大部分线程长时间处于sending data的状态 real <real@admin99.net> mysql Tue, 18 Nov 2008 14:23:45 +0000 http://www.admin99.net/read.php?403
有台服务器，访问量挺大，每天近250w动态pv，数据库查询平均每秒近600次
另一台服务器，跑的程序跟这台一样，不过只有每天约40w动态pv
前段时间连续卡死过几次，当时的状态是
服务器没崩溃，数据库可正常登陆。只是所有的查询都卡在“sending data”状态，长时间无法执行完，这些简单的sql语句，有时候集中在A表上，有时候集中在B表上，同时还有一些卡死在locked状态或update状态

看mysql的说明，sending data状态表示两种情况，一种是mysql已经查询了数据，正在发给客户端；另一种情况是，mysql已经知道某些数据需要去什么地方读取，正在从数据文件中读取

mysql官方说，这不是mysql的bug，但是官方也没说怎么处理......那么，看情况，就应该是配置方面的问题了。
首先从sql优化的角度来查了查，那些卡死的sql语句，都是简单查询，消耗非常低，索引做的非常好，所以觉得应该不是sql语句的问题。而且慢查询日志里也没有出现慢查询。

把表都做了优化，就是optimize table ，过几天发现，还是会出现卡死的情况.....

后来考虑增加并发性能，增加了key_buffer thread_cache 等一系列的内存配置，发现没什么作用。情况依旧

再后来，把query_cache减小到默认值 16M，把一些不怎么变动的数据，做了静态化。惊奇的发现，12天过去了，没再出过问题......

后来想想，修改query_cache可能对这个问题有些帮助，毕竟数据更新比较频繁，query_cache的更新也很频繁。不过看mysql的状态，query_cache的命中率还是相当高的，差不多75％。

觉得问题可能出在程序上，只是没查出来。后来静态化的那些内容，是一些产品的说明文字，一般一个产品的说明也就三五十个汉字。

这里出问题的嫌疑比较大，一个页面有七八个产品，加起来可能三五百个汉字，虽然不多，不过查询很频繁，从这个表上查询的数据量应该是很可观的，mysql会频繁的从这个表拿数据。不过，不过有时候卡死的语句并不是在查询这个表......

手头没有好使的工具，郁闷。反正问题貌似好了，先放下备案吧，等以后水平高些，再来查。
Tags - mysql , 性能优化 ]]> http://www.admin99.net/read.php?399 mysql日志中的一个错误，关于innodb_log_file_size real <real@admin99.net> mysql Sat, 15 Nov 2008 07:24:07 +0000 http://www.admin99.net/read.php?399

引用

081103 15:05:44 InnoDB: ERROR: the age of the last checkpoint is 9433679,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

查了一下是设置的innodb_log_file_size太小了，加大之后就好了，步骤如下
关闭mysql
修改my.cnf 将innodb_log_file_size从原来默认的5m改为100m
将mysql/data目录下的ib_logfile0，ib_logfile1这两个文件移走
启动mysql
Tags - mysql ]]> http://www.admin99.net/read.php?395 转载 mysql 优化的一些小窍门 real <real@admin99.net> mysql Sat, 08 Nov 2008 14:48:36 +0000 http://www.admin99.net/read.php?395 * 尽量使用MyISAM表,除非必须使用其他类型,因为MyISAM类型的总体读写效率是相当高的,缺点是表级锁,而不是行/页级锁.
* 善用EXPLAIN来帮助你分析查询优化情况
* 如果需要对一个较大的且并发读写较多的数据表做GROUP BY等统计操作,建议使用摘要表来存储统计信息,定期更新统计表,这可能获得很大的性能改善.
* 查询时如果有ORDER BY分句的话,注意让它的字段顺序和索引字段顺序对应,这样能加快排序速度
* 如果有一个多字段索引,则查询时,必须按照索引顺序来使用,否则该索引不会用到.例如:
索引`idx_`(col1, col2, col3),那么查询SELECT .... FROM ... WHERE col1=1 AND col2=2;使用索引,而查询... WHERE col2=2 AND col3=3;或... WHERE col1=1 AND col3=3;则不使用索引.
* WHERE中的条件如果有恒量类型的(如 `field` = 1),就尽量放在前面,这样能更快的执行过滤.
* 2 个表连接时,连接字段的类型最好一致(包括字段长度),这样的话索引速度快多了.
* 大部分情况下,字符类型的字段索引值需要一部分,例如CREATE INDEX char_idx ON tbl1 ( name(10) );
* 尽量使用最合适的数据类型,能使用ENUM就不使用TINYINT,能使用SMALLINT就不使用MEDIUMINT.这样能节省存储空间,增加数据存储量,提高搜索速度.不要担心这样会对省级产生很大的影响,因为加入从TINYINT类型改变为INT的话,并不会改变原来的数据.
* 如果知道某个表总是频繁使用的话,可以把它放到hot_cache中,用以下方法:

SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX `xxx` IN hot_cache;

* 把拖沓复杂,速度慢的的查询分解成多个简洁明了的查询,这样尽管查询次数多了,但是总体速度和效率却可能反而更高了,而且也减少了锁表的可能.
* 执行查询时,尽量不使用外部函数,因为这样的话就无法使用可能存在的索引,并且无论如何都会极大地降低效率.如:... WHERE `create_time` > UNIX_TIMESTAMP(NOW());这样的查询.可以在程序中把当前的时间取得,然后直接执行构造好了的SQL语句.
* 在索引字段上使用 LIKE 查询时,左边不要使用 '%' 修饰符,这样就可以利用索引,否则无法使用索引.如... `name` LIKE 'yejr%';.
* 如果有可能,多使用存储过程,这大概能获得 22% 的性能提高.
* 如果并发访问量相对最大连接数小多了的话,最好使用永久连接,这样能节省不少连接时的系统资源损耗.
* 定期的在MyISAM表上执行OPTIMIZE TABLE,这能整理随便,提高索引效率.
* 如果你主要按 col1，col2，...顺序检索记录,请在对表大量更改后执行ALTER TABLE ... ORDER BY col1, col2, ...语句,这可以获得更好的性能.
* 对于频繁更改的MyISAM表,应尽量避免更新所有变长字段(VARCHAR、BLOB和TEXT).
* 对于记录总数超过500万的单表,就应该赶紧考虑分表了.分表策略有多种,比如按ID号段,或者按时间切分,等等.
* 创建数据表时尽量指定字段不能为NULL,并且有默认值.
* 使用LOAD DATA,而不是使用大批量的INSERT语句来导入数据.
* 使数据表名和字段名尽可能的短,例如在user表中使用字段名name,而不是user_name.
* 用DELAY_KEY_WRITE = 1选项让MyISAM更快地更新索引,因为在表关闭之前它们不刷新到硬盘上.缺点是如果服务器如果突然被杀掉了,重启之后就必须运行myisamchk修复索引才行.
* 采用复制机制来分摊读数据的负载,把写数据只放在主服务器上,把读平均分摊到各个从服务器上,能大大提高系统负载.
Tags - mysql ]]>