MySQL FAQ

MySQL FAQ
MySQL 常见问题

infobright下如何使用utf8字符集

目前infobright应用越来越多了,有些场景下需要和台管理系统共用,因此需要同时存在brighthouse和myisam两种引擎。
这时候,如果需要brighthouse引擎支持utf8字符集,需要:
1. 数据库对象创建时务必使用utf8字符集,这点尤为关键,否则不可支持utf8;
2. 数据表对象创建时也使用utf8字符集;
3. 导入文件提前转换成utf8字符集;
4. 连接infobright时,执行set names utf8;
5. 导入文件,查看字符集是否正确;

另一种场景下,可能myisam表也需要支持utf8,这个相对比较麻烦:
1. 数据库对象创建时无所谓,不强制必须是utf8;
2. 数据表对象创建时务必使用utf8字符集;
3. 将导入文件全部转换成utf8字符集的INSERT语法,直接写入数据,infobright不支持LOAD DATA INFILE方式导入utf8字符集的文件;
4. 也可以将其他非字符型字段导入后,再用update进行更新;

InnoDB引擎数据表压缩特性测试

一、前言
Innodb Plugin引擎开始引入多种格式的行存储机制,目前支持:Antelope、Barracuda两种。其中Barracuda兼容Antelope格式。
另外,Innodb plugin还支持行数据压缩特性,不过前提是采用Barracuda行存储格式。
表空间启用压缩的前提是innodb表空间文件存储格式修改成:Barracuda,需要修改2个选项:
innodb_file_format = "Barracuda"
innodb_file_format_max = "Barracuda"

下面是对比测试结果
二、表空间压缩比
1. 某项目数据表压缩比
2.1 数据表tabA
压缩之前
-rw-rw---- 1 mysql mysql 19038208 Mar 21 13:59 tabA.ibd(18.1G)
压缩之后
-rw-rw---- 1 mysql mysql 9.2G Mar 21 19:11 tabA.ibd
相差:12414976 ~= 12124 MB ~= 11.83 Gb,节约49.32%

TPCC-MySQL使用手册

一、 下载工具包
Tpcc-mysql是percona基于tpcc衍生出来的产品,专用于mysql基准测试,其源码放在bazaar(Bazaar是一个分布式的版本控制系统,采用 GPL 许可协议,可运行于 Windows、GNU/Linux、UNIX 以及 Mac OS 系统之上。Bazaar 由 Canonical 公司(Ubuntu母公司)赞助)上,因此还需要先安装bazaar客户端。

使用root安装rpm包

rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

然后就可以开始安装bzr客户端了:

yum install bzr 

之后,就可以开始用bzr客户端下载tpcc-mysql源码了。

cd tmp
bzr branch lp:~percona-dev/perconatools/tpcc-mysql

二、编译安装
编译非常简单

cd /tmp/tpcc-mysql/src
make

然后就会在 /tmp/tpcc-mysql 下生成 tpcc 命令行工具 tpcc_load 、 tpcc_start

[MySQL FAQ]系列-关于设置innodb buffer pool size

按照惯例,如果前端应用程序采用长连接的话,那么innodb buffer pool最高可设置为物理内存大小的80%。
不过部分在线DB由于并发连接数较高,每个线程分配的内存较多,或由于业务上升,并发事务数突然较大幅度提升,加上innodb buffer pool较大,导致了严重的内存交换(swap)发生。

鉴于此,我们建议在这些活跃度较高/并发连接数较高的在线DB服务器上,适当调低innodb buffer pool的大小(例如先调低为60%),
同时也适当调低各线程级别的内存参数,例如:tmp_table_size, sort_buffer_size等,避免因为内存交换而影响服务器性能。尤其是 tmp_table_size,不少人以为是全局变量,设置的非常大,甚至见过一个设置为 1GB 的,太吓人了。

如果绝大多数引擎是InnoDB的话,建议调低key_buffer_size到很小的值,同时可以关闭query cache,现在它基本是个鸡肋了,有些时候甚至还会导致性能受到影响。

[MySQL FAQ]系列-关于连接MySQL报错lost connection 和 gone away

一般频繁出现的话,才需要关注,一天出现几次属于正常情况。
频繁出现的原因一般有:
1. 网络,包括网络质量,服务器网卡驱动,程序连接数据库方式:ODBC/API,都是有区别的;这里的网络问题,可能出现在客户端,也可能出现在服务端
2. 如果使用ODBC的话,还需要注意部分ODBC版本可能存在bug,导致有问题
3. 服务端自身问题,例如mysqld不稳定,连接数超限,或者连接超时,或者由于dns反解析的问题导致连接异常
4. 其他问题,自己发挥吧 O(∩_∩)O哈哈~

[MySQL FAQ]系列-net_buffer_length选项对数据备份及恢复影响

有一次和朋友讨论到 net-buffer-length 可能对mysqldump导出及恢复有影响,对此测试了一下,发现影响很小,基本可以忽略不计,下面是对比测试结果。

说明:执行mysqldump时,net buffer length的最大上限是16Mb,默认值是1Mb,下面是测试结果贴图:

从上面的对比结果可以看出来,该选项的调整对导出所需时间影响不大,仅对导出文件有一定影响,但也很小;同样地,对数据恢复的影响也很小。

使用Percona Xtrabackup备份SLAVE数据

现在我们可以很方便的用Xtrabackup取代ibbackup,作为innodb的在线热备工具使用。通常,我们会选择在SLAVE上进行备份,以减小MASTER的压力。 innobackupex是封装后的perl脚本,用于调度xtrabackup进行备份,附加了不少辅助功能,非常实用,下面是一个常见的innobackupex备份例子:

技术相关: 

[MySQL FAQ]系列 -- MySQL执行ALTER TABLE导致读不一致性问题

转发一下某网友(Howard)的来信,先讨论一下,稍后再给结论

你好:

我现在有个关于mysql的问题一点思路都没有,想问下你,麻烦你有时间了看下。

另外你一般有没有一个活跃的论坛或者小组之类的?

mysql的版本是Server
version: 5.1.51-community-log MySQL Community Server (GPL)

技术相关: 

[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号被重用的情况。

技术相关: 

页面

Subscribe to RSS - MySQL FAQ