InnoDB

InnoDB相关

[MySQL优化案例]系列 -- InnoDB主键设计

众所周知,InnoDB是clustered-index table,因此对于InnoDB而言,主键具有特殊意义。可以通过主键直接定位到对应的某一数据行记录的物理位置,主键索引指向对应行记录,其他索引则都指向主键索引;因此,可以这么说,InnoDB其实就是一个 B-树索引,这棵B-树的索引就是主键,它的值则是对应的行记录。
在InnoDB数据表设计中,我们需要注意几点:

  • 1. 显式的定义一个 INT 类型自增字段的主键,这个字段可以仅用于做主键,不做其他用途
  • 2. 如果不显式定义主键的话,可能会导致InnoDB每次都需要对新数据行进行排序,严重损害性能
  • 3. 尽量保证不对主键字段进行更新修改,防止主键字段发生变化,引发数据存储碎片,降低IO性能
  • 4. 如果需要对主键字段进行更新,请将该字段转变成一个唯一索引约束字段,另外创建一个没有其他业务意义的自增字段做主键
  • 5. 主键字段类型尽可能小,能用SMALLINT就不用INT,能用INT就不用BIGINT
  • 6. 主键字段放在数据表的第一顺序

[MySQL FAQ]系列 -- 用MySQL实现发号器

问题:用MySQL实现发号器功能,确保每次取到的ID号都是唯一的
实现:下面是一个大致的思路,抛个砖,欢迎回帖。
根据号段大小,决定是否分成多个表,每个表事先填充各个不同的号段。
每个应用端取号时,设置事务隔离级别为:REPEATABLE READ,并且采用下面的方式读取数据

SELECT `ID` FROM `ID_RANGE_XX` ORDER BY ID LIMIT 1 FOR UPDATE

在上述情境中,只要选择某个ID号,那么其他终端也在读取该号时,会产生锁等待,而不会发生ID号被重用的情况。

技术相关: 

[MySQL FAQ]系列 -- 数据不算大,备份却非常慢

问题

环境
硬件:DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram
软件:2.6.9-55.ELsmp x86_64, mysql 5.1.x

现象
2个库,其中1个业务库下有20多个表,表文件大小总量不到2G。
另一个为日志库,下400多个表,大致是每天会产生5个表,其中有一个表较大,约400MB,总量约40多GB。
每次备份耗时较长,最严重的一次花了5个多小时才完成。
业务库为当前活动库,日志库则主要用作备份,每天日志归档,过期数据表很少有读写请求。

技术相关: 

[MySQL FAQ]系列 -- show engine innodb status显示信息不全?

问题:
执行 show engine innodb status\G 时,显示的信息不全,DEADLOCK相关信息太多,后面的都没了

原因:
这是mysql客户端的一个bug:BUG#19825,交互式客户端限制了输出信息最大为 64KB,因此更多的信息无法显示。

MySQL优化 之 Discuz论坛优化 -- 续

很早以前写过一个文章,是关于discuz论坛的优化:MySQL优化 之 Discuz论坛优化。写的时候是2006年,没想到过了这么久,discuz论坛的问题还是困扰着很多网友,其实从各论坛里看到的问题总结出来,很关键的一点都是因为没有将数据表引擎转成InnoDB导致的,discuz在并发稍微高一点的环境下就表现的非常糟糕,产生大量的锁等待,这时候如果把数据表引擎改成InnoDB的话,我相信会好很多。这次就写个扫盲贴吧。

1. 启用innodb引擎,并配置相关参数

技术相关: 

利用XtraBackup实现InnoDB表空间文件跨服务器迁移

percona最新发布的XtraBackup不仅可以到处XtraDB表空间文件,现在还支持导出InnoDB表空间文件,从而可以实现InnoDB表空间文件的跨服务器平滑迁移,而无须像 InnoDB数据表空间文件平滑迁移 这么麻烦了。具体内容查看原文:Impossible - possible, moving InnoDB tables between servers

技术相关: 

[MySQL FAQ]系列 -- InnoDB表报错: table is full

同事碰到麻烦,寻求帮忙,问题是这样的:
有个InnoDB表,想要用 LOAD DATA INFILE 的方式倒数据进去,发现报错:table is full。
我看了一下,日志中没有相关可用信息,该表使用的是共享表空间,总共6个ibdata*文件,只有2个文件的修改时间是最新的,觉得可能不是因为表空间慢的缘故,于是尝试插入少量数据试试看先。分多次插入10,20,100条记录都没问题,一次性插入500多条记录时,就又报table is full了。看来,事务没有问题,再把焦点转会表空间问题上来。尝试性的关闭mysqld,新加一个表空间文件,启动,再插入更多数据,发现这次没问题了,搞定。

[MySQL FAQ]系列 -- InnoDB报错,buffer不够用

一朋友发来消息,说他的mysql报错,日志大致如下:

090318 15:16:35 InnoDB: WARNING: over 4 / 5 of the buffer pool is occupied by
InnoDB: lock heaps or the adaptive hash index! Check that your
InnoDB: transactions do not set too many row locks.
InnoDB: Your buffer pool size is 16 MB. Maybe you should make
InnoDB: the buffer pool bigger?
InnoDB: Starting the InnoDB Monitor to print diagnostics, including
InnoDB: lock heap and hash index sizes.

 

[MySQL优化案例]系列 -- 在5.1的分区功能中混用InnoDB和MyISAM

MySQL 5.1中增加了分区(partition)功能,有了这个功能,以前很头疼的分表方案,现在就变得不再那么麻烦了。不过,如果采用了MyISAM引擎,而且在数据量较大的情境下,并发读写仍然是个问题,尤其是对索引的更新。为此,可以在分区表中采用MyISAM和InnoDB引擎混用的方法,大致如下:

InnoDB数据表空间文件平滑迁移

前言

InnoDB存储引擎满足了MVCC和ACID特性,在需要支持事务的环境下必不可少。有些环境下,采用InnoDB可能效果比MyISAM还要来的好。不过,在很多人眼中看来,InnoDB表空间文件由于无法实现跨服务器平滑迁移,因此不愿意使用。实际情况真是这样吗?本文就来探讨一下InnoDB表空间文件的平滑迁移可能性。

如何迁移?

从MySQL文档中我们了解到,InnoDB的表空间可以是共享的或独立的。如果是共享表空间,则所有的表空间都放在一个文件里:ibdata1,ibdata2..ibdataN,这种情况下,目前应该还没办法实现表空间的迁移,除非完全迁移,因此不在本次讨论之列;我们只讨论独立表空间的情况。

页面

Subscribe to RSS - InnoDB