MYSQL使用INNODB时及时清理旧版本数据
2011-08-27 23:49
447 查看
InnoDB’s tablespace can grow very large in a writeheavy environment. If transactions stay open for a long time (even if they’re not doing any work) and they’re using the default REPEATABLE READ transaction isolation level, InnoDB
won’t be able to remove old row versions, because the uncommitted transactions will still need to be able to see them. InnoDB stores the old versions in the tablespace, so the it continues to grow as more data is updated. Sometimes the problem isn’t uncommitted
transactions, but just the workload: the purge process is only a single thread, and it might not be able to keep up with the number of old row versions that need to be purged.
In either case, the output of SHOW INNODB STATUS can help you pinpoint the problem.Look at the first and second lines of the TRANSACTIONS section, which show the current transaction number and the point to which the purge has
completed. If the difference is large, you may have a lot of unpurged transactions. Here’s an example:
------------
TRANSACTIONS
------------
Trx id counter 0 80157601
Purge done for trx's n:o <0 80154573 undo n:o <0 0
The transaction identifier is a 64-bit number composed of two 32-bit numbers, so you might have to do a little math to compute the difference. In this case it’s easy, because the high bits are just zeros: there are 80157601 – 80154573
= 3028 potentially unpurged transactions (innotop can do this math for you). We said “potentially” because a large difference doesn’t necessarily mean there are a lot of unpurged rows. Only transactions that change data will create old row versions,
and there may be many transactions that haven’t changed any data (conversely, a single transaction could have changed many rows).
If you have a lot of unpurged transactions and your tablespace is growing because of it, you can force MySQL to slow down enough for InnoDB’s purge thread to keep up. This may not sound attractive, but there’s no alternative.
Otherwise, InnoDB will keep writing data and filling up your disk until the disk runs out of space or the tablespace reaches the limits you’ve defined. To throttle the writes, set the innodb_max_purge_lag variable to a value other than 0. This value indicates
the maximum number of transactions that can be waiting to be purged before InnoDB starts to delay further queries that update data. You’ll have to know your workload to decide on a good value. As an example, if your average transaction affects 1 KB of rows
and you can tolerate 100 MB of unpurged rows in your tablespace, you could set the value to 100000. Bear in mind that unpurged row versions impact all queries, because they effectively make your tables and indexes larger. If the purge thread simply can’t keep
up, performance can decrease dramatically.
--如果purge进程跟不上事务更新的速度,那么表和索引文件的大小就会因此增长的很快,而且存在多种版本,innodb在读取或者更新的时候就要进行各种判断,因而性能会急剧降低. Setting the innodb_max_purge_lag variable will slow down performance too, but it’s the lesser of the two evils.--相比而言,设置lag的值比不设置要好.
innodb的purge策略非产复杂,相比而言,在从库上,可以把事务隔离等级设置为read-uncommitted,绕开了innodb的mvcc,也就避免了purge的过程,从而提高性能.同时,对于复杂的事务,就需要读主库了.
won’t be able to remove old row versions, because the uncommitted transactions will still need to be able to see them. InnoDB stores the old versions in the tablespace, so the it continues to grow as more data is updated. Sometimes the problem isn’t uncommitted
transactions, but just the workload: the purge process is only a single thread, and it might not be able to keep up with the number of old row versions that need to be purged.
In either case, the output of SHOW INNODB STATUS can help you pinpoint the problem.Look at the first and second lines of the TRANSACTIONS section, which show the current transaction number and the point to which the purge has
completed. If the difference is large, you may have a lot of unpurged transactions. Here’s an example:
------------
TRANSACTIONS
------------
Trx id counter 0 80157601
Purge done for trx's n:o <0 80154573 undo n:o <0 0
The transaction identifier is a 64-bit number composed of two 32-bit numbers, so you might have to do a little math to compute the difference. In this case it’s easy, because the high bits are just zeros: there are 80157601 – 80154573
= 3028 potentially unpurged transactions (innotop can do this math for you). We said “potentially” because a large difference doesn’t necessarily mean there are a lot of unpurged rows. Only transactions that change data will create old row versions,
and there may be many transactions that haven’t changed any data (conversely, a single transaction could have changed many rows).
If you have a lot of unpurged transactions and your tablespace is growing because of it, you can force MySQL to slow down enough for InnoDB’s purge thread to keep up. This may not sound attractive, but there’s no alternative.
Otherwise, InnoDB will keep writing data and filling up your disk until the disk runs out of space or the tablespace reaches the limits you’ve defined. To throttle the writes, set the innodb_max_purge_lag variable to a value other than 0. This value indicates
the maximum number of transactions that can be waiting to be purged before InnoDB starts to delay further queries that update data. You’ll have to know your workload to decide on a good value. As an example, if your average transaction affects 1 KB of rows
and you can tolerate 100 MB of unpurged rows in your tablespace, you could set the value to 100000. Bear in mind that unpurged row versions impact all queries, because they effectively make your tables and indexes larger. If the purge thread simply can’t keep
up, performance can decrease dramatically.
--如果purge进程跟不上事务更新的速度,那么表和索引文件的大小就会因此增长的很快,而且存在多种版本,innodb在读取或者更新的时候就要进行各种判断,因而性能会急剧降低. Setting the innodb_max_purge_lag variable will slow down performance too, but it’s the lesser of the two evils.--相比而言,设置lag的值比不设置要好.
innodb的purge策略非产复杂,相比而言,在从库上,可以把事务隔离等级设置为read-uncommitted,绕开了innodb的mvcc,也就避免了purge的过程,从而提高性能.同时,对于复杂的事务,就需要读主库了.
相关文章推荐
- VS2013与MySql建立连接;您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- phpstudy2016最新版本mysql无法使用innodb的问题解决
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- 您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- 【MySQL】InnoDB引擎ibdata文件损坏/删除后使用frm和ibd文件恢复数据
- MySQL配置内存使用之innodb数据字典
- VS2013与MySql建立连接;您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- Hadoop2.5.2+Sqoop-1.4.6(2.0以上的版本hadoop使用)伪分布式实现mysql数据上传到ndfs
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- MySQL 数据库清理MyISAM Innodb表(支持MySQL5.1.6以上的版本)
- 您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- 您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- mysql权限和使用注意事项及mysql 数据类型详解和innodb,myisam区别
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- 使用参数innodb_file_per_table支持MySQL InnoDB表数据共享空间自动收缩
- mysql innodb引擎 长时间使用后,数据文件远大于实际数据量,导致空间不足。
- 您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧
- VS2013与MySql建立连接;您的项目引用了最新实体框架;但是,找不到数据链接所需的与版本兼容的实体框架数据库 EF6使用Mysql的技巧