1.如果 Unixtop或 Windows任务管理器(Task Manager)显示服务的 CPU 占用率小于 70%，(shows that the CPU usage percentage with your workload is less than 70 %,）你的系统瓶颈可能在磁盘读写上。或许你提交了大量的事务，或者是缓冲池(buffer pool)太小了。将缓冲池设大点会有所帮助，但一定要注意不能大于物理内存的 80%。
2.在一个事务中包含几个修改。如果事务对数据库进行了修改，那么在这个事务提交时 InnoDB 必须刷新日志到磁盘上。因为硬盘的旋转速度通常至多为 167 转/秒，那么只要磁盘不欺骗操作系统，提交的事务数目限止也同样为 167 次/秒·用户。(先刷日志到磁盘，再从内存中刷数据到磁盘)
3.如果掉失最近的几个事务无所谓的话，可以在my.cnf文件中将参数innodb_flush_log_at_trx_commit设置为 0。InnoDB 无论如何总是尝试一秒刷新(flush)一次日志，尽管刷新并不能得到保证。
4.将日志文件(log files)设大一点，使日志文件的总和正好与缓冲池(buffer pool)一样大。当 InnoDB 用光日志文件的空间时，它不得不在一个时间点上将缓冲池内修改过的内容写到磁盘上。 小的日志文件可能引起不必要的磁盘写操作。但是大的日志文件的缺点就是在数据恢复时将占用较长的时间。
5.同样 log buffer 尽量设大点，比如说 8 MB。
6.如果要存储变长的字符串或字段可能会包含大量的 NULLs，请使用VARCHAR型字段代替CHAR。一个CHAR(n)字段总是使用 n bytes 来存储数据，即使这个字符串很短或是一个 NULL 值。较小的表更加适合缓冲池同时能够减少磁盘 I/O 。
7.(适合从 3.23.41 以上版本) 在某些版本的 Linux 和 Unixes 中，使用 Unixfsync或其它类似的方法将文件刷新到磁盘是异常地慢的。InnoDB 默认的方法就是fsync。如果你对数据库系统的磁盘写性能不能感到满意，你可以尝试在my.cnf中将innodb_flush_method设置为O_DSYNC，尽管O_DSYNC选项在多数的系统上看起来比较慢。
8.在向 InnoDB 导入数据时，请确认 MySQL 没有打开autocommit=1。否则每个插入语句都要将 log 刷新到磁盘。在你的 SQL 导入文件的第一行加入
set autocommit=0;并在最后一行加入commit;
如果使用mysqldump选项--opt，你将会得到一个快速导入 InnoDB 表的转储(dump)文件，甚至可以不再使用上面所提的set autocommit=0; ... commit;。
9.小心 insert 集全的大回滚(roolback)：在插入时 InnoDB 使用插入缓冲来减少磁盘 I/O，但在相应的回滚中却没有使用这样的机制。一个 disk-bound rollback 可能会花费相应插入时间的 30 倍。如果发生一个失控的回滚，你可以查看第 6.1 章节的技巧来停止它。
10.同样也要小心一个大的 disk-bound 的操作。使用DROP TABLE或TRUNCATE(从 MySQL-4.0 以上) 来清空一个表，而不要使用DELETE FROM yourtable。
11.如果需要插入大量记录行可以使用多行(multi-line)的INSERT来减少客户端与服务器端的通信开销：
INSERT INTO yourtable VALUES (1, 2), (5, 5);
这个技巧对插入任何表均有效，而不仅仅是 InnoDB。
12.如果在辅键上有UNIQUE约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将唯一键检查(uniqueness check)关闭来提高数据导入速度：
SET UNIQUE_CHECKS=0;一个大的表导入这将减少大量的磁盘 I/O，因为这时 InnoDB 可能使用自身的插入缓冲来分批地记录辅助索引。
13.如果在表中有一个子FOREIGN KEY约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将外键检查(foreign key check)关闭来提高数据导入速度：
SET FOREIGN_KEY_CHECKS=0;
对一个大的表导入这将减少大量的磁盘 I/O。
数据库设计：尽量把数据库设计的更小的占磁盘空间
1).尽可能使用更小的整数类型.(mediumint就比int更合适).
2).尽可能的定义字段为not null,除非这个字段需要null.
3).如果没有用到变长字段的话比如varchar,那就采用固定大小的纪录格式比如char.
4).表的主索引应该尽可能的短.这样的话每条纪录都有名字标志且更高效.
5).只创建确实需要的索引。索引有利于检索记录，但是不利于快速保存记录。如果总是要在表的组合字段上做搜索，那么就在这些字段上创建索引。索引的第一部分必须是最常使用的字段.如果总是需要用到很多字段，首先就应该多复制这些字段，使索引更好的压缩。
6).所有数据都得在保存到数据库前进行处理。
7).所有字段都得有默认值。
8).在某些情况下,把一个频繁扫描的表分成两个速度会快好多。在对动态格式表扫描以取得相关记录时，它可能使用更小的静态格式表的情况下更是如此。
系统的用途：
1).尽量使用长连接.
2).explain 复杂的SQL语句。
3).如果两个关联表要做比较话，做比较的字段必须类型和长度都一致.
4).LIMIT语句尽量要跟order by或者 distinct.这样可以避免做一次full table scan.
5).如果想要清空表的所有纪录,建议用truncate table tablename而不是delete from tablename.
6).能使用STORE PROCEDURE 或者 USER FUNCTION的时候.
7).在一条insert语句中采用多重纪录插入格式.而且使用load data infile来导入大量数据，这比单纯的indert快好多.
8).经常OPTIMIZE TABLE 来整理碎片.
9).还有就是date 类型的数据如果频繁要做比较的话尽量保存在unsigned int 类型比较快。
系统的瓶颈：
1).磁盘搜索.
并行搜索,把数据分开存放到多个磁盘中，这样能加快搜索时间.
2).磁盘读写(IO)
可以从多个媒介中并行的读取数据。
3).CPU周期
数据存放在主内存中.这样就得增加CPU的个数来处理这些数据。
4).内存带宽
当CPU要将更多的数据存放到CPU的缓存中来的话,内存的带宽就成了瓶颈.
2.在一个事务中包含几个修改。如果事务对数据库进行了修改，那么在这个事务提交时 InnoDB 必须刷新日志到磁盘上。因为硬盘的旋转速度通常至多为 167 转/秒，那么只要磁盘不欺骗操作系统，提交的事务数目限止也同样为 167 次/秒·用户。(先刷日志到磁盘，再从内存中刷数据到磁盘)
3.如果掉失最近的几个事务无所谓的话，可以在my.cnf文件中将参数innodb_flush_log_at_trx_commit设置为 0。InnoDB 无论如何总是尝试一秒刷新(flush)一次日志，尽管刷新并不能得到保证。
4.将日志文件(log files)设大一点，使日志文件的总和正好与缓冲池(buffer pool)一样大。当 InnoDB 用光日志文件的空间时，它不得不在一个时间点上将缓冲池内修改过的内容写到磁盘上。 小的日志文件可能引起不必要的磁盘写操作。但是大的日志文件的缺点就是在数据恢复时将占用较长的时间。
5.同样 log buffer 尽量设大点，比如说 8 MB。
6.如果要存储变长的字符串或字段可能会包含大量的 NULLs，请使用VARCHAR型字段代替CHAR。一个CHAR(n)字段总是使用 n bytes 来存储数据，即使这个字符串很短或是一个 NULL 值。较小的表更加适合缓冲池同时能够减少磁盘 I/O 。
7.(适合从 3.23.41 以上版本) 在某些版本的 Linux 和 Unixes 中，使用 Unixfsync或其它类似的方法将文件刷新到磁盘是异常地慢的。InnoDB 默认的方法就是fsync。如果你对数据库系统的磁盘写性能不能感到满意，你可以尝试在my.cnf中将innodb_flush_method设置为O_DSYNC，尽管O_DSYNC选项在多数的系统上看起来比较慢。
8.在向 InnoDB 导入数据时，请确认 MySQL 没有打开autocommit=1。否则每个插入语句都要将 log 刷新到磁盘。在你的 SQL 导入文件的第一行加入
set autocommit=0;并在最后一行加入commit;
如果使用mysqldump选项--opt，你将会得到一个快速导入 InnoDB 表的转储(dump)文件，甚至可以不再使用上面所提的set autocommit=0; ... commit;。
9.小心 insert 集全的大回滚(roolback)：在插入时 InnoDB 使用插入缓冲来减少磁盘 I/O，但在相应的回滚中却没有使用这样的机制。一个 disk-bound rollback 可能会花费相应插入时间的 30 倍。如果发生一个失控的回滚，你可以查看第 6.1 章节的技巧来停止它。
10.同样也要小心一个大的 disk-bound 的操作。使用DROP TABLE或TRUNCATE(从 MySQL-4.0 以上) 来清空一个表，而不要使用DELETE FROM yourtable。
11.如果需要插入大量记录行可以使用多行(multi-line)的INSERT来减少客户端与服务器端的通信开销：
INSERT INTO yourtable VALUES (1, 2), (5, 5);
这个技巧对插入任何表均有效，而不仅仅是 InnoDB。
12.如果在辅键上有UNIQUE约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将唯一键检查(uniqueness check)关闭来提高数据导入速度：
SET UNIQUE_CHECKS=0;一个大的表导入这将减少大量的磁盘 I/O，因为这时 InnoDB 可能使用自身的插入缓冲来分批地记录辅助索引。
13.如果在表中有一个子FOREIGN KEY约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将外键检查(foreign key check)关闭来提高数据导入速度：
SET FOREIGN_KEY_CHECKS=0;
对一个大的表导入这将减少大量的磁盘 I/O。
数据库设计：尽量把数据库设计的更小的占磁盘空间
1).尽可能使用更小的整数类型.(mediumint就比int更合适).
2).尽可能的定义字段为not null,除非这个字段需要null.
3).如果没有用到变长字段的话比如varchar,那就采用固定大小的纪录格式比如char.
4).表的主索引应该尽可能的短.这样的话每条纪录都有名字标志且更高效.
5).只创建确实需要的索引。索引有利于检索记录，但是不利于快速保存记录。如果总是要在表的组合字段上做搜索，那么就在这些字段上创建索引。索引的第一部分必须是最常使用的字段.如果总是需要用到很多字段，首先就应该多复制这些字段，使索引更好的压缩。
6).所有数据都得在保存到数据库前进行处理。
7).所有字段都得有默认值。
8).在某些情况下,把一个频繁扫描的表分成两个速度会快好多。在对动态格式表扫描以取得相关记录时，它可能使用更小的静态格式表的情况下更是如此。
系统的用途：
1).尽量使用长连接.
2).explain 复杂的SQL语句。
3).如果两个关联表要做比较话，做比较的字段必须类型和长度都一致.
4).LIMIT语句尽量要跟order by或者 distinct.这样可以避免做一次full table scan.
5).如果想要清空表的所有纪录,建议用truncate table tablename而不是delete from tablename.
6).能使用STORE PROCEDURE 或者 USER FUNCTION的时候.
7).在一条insert语句中采用多重纪录插入格式.而且使用load data infile来导入大量数据，这比单纯的indert快好多.
8).经常OPTIMIZE TABLE 来整理碎片.
9).还有就是date 类型的数据如果频繁要做比较的话尽量保存在unsigned int 类型比较快。
系统的瓶颈：
1).磁盘搜索.
并行搜索,把数据分开存放到多个磁盘中，这样能加快搜索时间.
2).磁盘读写(IO)
可以从多个媒介中并行的读取数据。
3).CPU周期
数据存放在主内存中.这样就得增加CPU的个数来处理这些数据。
4).内存带宽
当CPU要将更多的数据存放到CPU的缓存中来的话,内存的带宽就成了瓶颈.
扫一扫
115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
