MySQL -- IT技术博客大学习 -- 共学习共进步！

• MySQL优化之 Discuz论坛MySQL通用优化

今日帮朋友优化号称日均数百万PV，数百万UV的论坛，后台DB采用R710(16G Ram，PERC 6/i 256MB BBU，4块 15K RPM SAS盘做raid 1+0，ext3文件系统，E5620 * 2)，这个配置看似也不错了，不过压力仍然较大，大量的请求处于：sending data和statistics状态。经过分析，确认瓶颈主要在......

• MySQL中like语句及相关优化器tips

like用的是 ‘%xx%’, 不符合前缀匹配的规则，因此用不上索引title，只能作全表扫描。以上为官方回答。但是如果是在 InnoDB这种聚集索引组织的表中，假设这个表单行很大，比如后面还有若干个类似memo的字段。这样聚集索引会很大，导致全表扫描需要读更多的磁盘。而理想情况应该是这个流程 1) 遍历title索引，从中读取和过滤所有title中匹配like条件的id 2) 用id到聚簇索引中读数据。在单行很大，而like能够过滤掉比较多语句的情况下，上面的流程肯定比全表扫描更快，也更省资源。

• 关于InnoDB索引长度限制的tips

有同学问到InnoDB的索引长度问题，简单说几个tips。大家经常碰到InnoDB单列索引长度不能超过767bytes，实际上联合索引还有一个限制是3072。

• mysql 初探

说是初探，其实也是学了很多年了，但是由于没有什么实践经验，所以没有真正的学以致用，近来无聊，看看以前貌似熟悉的知识还在否？ 1.distinct——select中的一个去重的关键字，问题如下。 a)distinct能否修饰*？实践证明是可以的，但是没有意义，因为数据库主键必不能重复，所以distinct没有达到去重的效果。 b)distinct能否修饰多个column？这是不行的，distinct只能用于所有column之前，查重的结果必是所有查询的column都相同才予以去除。 2.order by 与 limit a)order by中的字符a和A是按ASCII排序的么？其实是一种设置，字符集是一种语言的所有字符，而校验是设置字符中那些是一样的。 b)limit后面数字的用法？有两种limit,一个参数仅仅表示选择行数，两个参数的第一个参数是从哪一行开始，第二个参数表示选择后面的多少

• Character set ‘#45′ 导致主从停止问题

在高版本对低版本的主从中，要注意不要用到低版本不支持的字符集（所以官方并不建议高版本的master同步到低版本的slave）。对于已经在Master的里面已经存在的binlog，要让主从能够继续同步，只能在slave_skip_errors里加上 22这个错误号。

• MySQL命令行按Delete键输出”~”的问题

MySQL 默认用了一个叫 libedit 的东西来替代 libreadline, 如果按 Delete/Home/End 键, 就会输出 “~”, 非常不好用. 解决方法很简单, 只要换回 libreadline 就 OK 了.

• 给MySQL的show table status结果做过滤

MySQL中可以使用 show table status 查看表的状态，但是不能像select 语句选出结果那样做结果过滤。有没有办法像select语句那样过滤呢，答案是有的，就是从information_schema库的tables表中查询。

• Transfer在MySQL数据库双主同步架构中的应用

有同学讨论到Transfer能否支持双主结构，答案是支持的，这里简要描述下。 Transfer既可以当作主从库之外的工具来用，也可以本身充当slave的角色。本文分别描述在这两种使用场景下的部署结构和切换动作。

• 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语法，直接写入数据，infobrig

• MySQL MongoDB SQL 对应

MySQL MongoDB SQL 对应

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

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

• ORACLE的几个函数在MYSQL里面的简单实现

最忌在做ORACLE到MYSQL得迁移，以下我写了三个简单的MYSQL里面米有的函数。供大家参考。

• 尝试mysqlbinlog的flashback功能

简介： mysqlbinlog flashback功能是淘宝彭立勋的一个很强劲的作品．主要功能：　对rows格式的binlog可以进行逆向操作．delete反向生成insert, update生成反向的update,insert反向生成delete．让dba同学们也有机会简单的恢复数据．可恢复:insert, update,delete相关的操作．

• PostgreSQL查询优化简介

总结一些有关PostgreSQL查询计划，查询优化的相关内容，比较基础。 SQL是一种申明性(declared)语言，也就是说，它并不是一种程序。它没有其他编程语言里的流控制语言，比如while，也无法控制操作顺序，比如有名的”goto”。 SQL只是描述一个结果，并非过程。结果一致，但如果过程不同，所带来的系统消耗可谓天差地远。所以所有的RDBMS里都需要有查询优化器来获得一条执行代价最小的方式来获取期望的结果。在PostgreSQL里，和查询优化器紧密相连的便是查询计划。

• ORACLE用户重命名

从oracle 11.2.0.2开始提供了用户重命名的新特性，在以前的版本中，如果想对用户重命名，一般来说是先创建一个新的用户并授权，然后将原用户下的所有对象导入，然后删除旧的用户！

• MySQL数据库性能优化之硬件瓶颈分析

在过往与很多人的交流过程中发现，在谈到基于硬件来进行数据库性能瓶颈分析的时候，常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备。个人觉得这其中可能存在一个非常大的误区。我们在谈论基于硬件进行优化的时候，不能仅仅将数据库使用的硬件划分为主机和存储两部分，而是需要进一步对硬件进行更细的分解，至少也应该分解到如下范畴：主机 CPU：仅仅只能决定运算速度，及时是运算速度都还取决于与内存之间的总线带宽以及内存本身的速度内存：大小决定了所能缓存的数据量，主要决定了热点数据的访问速度磁盘：大小：决定了你最终能存放多少数据量转速：决定了你每一次IO请求的延时时间，也就是决定了我们常说的IOPS和MBPS 数目：磁盘数目决定了类型

• MySQL数据库负载很高连接数很多怎么处理

在MySQL数据库连接数很多,而且大多属于活跃的状态时MySQL机器基本上负载很高,属于基本上快要死去的状态了. 这时怎么办呢? 有可能两个办法. 第一先限制Innodb的并发处理.如果innodb_thread_conncurrency = 0 可以先改成 16或是64 看机器压力,如果非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务. 处理方法: set global innodb_thread_conncurrency=16; 第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了. DB在了,总是可以用来加载一下数据,当数据加载

• MySQL 中 QueryCache 的锁模型

有同学在问 MySQL中 QueryCache(QC)的锁是 “全局锁”还是 “表锁”。这里简要说明一下。 1、 QC基本概念这个是实现在MySQL层(非引擎层)的一个内存结构，基本规则是将满足一定条件的查询结果缓存在内存中，若同样的查询再执行第二次，而且缓存没有失效，则可以直接返回查询结果，无需到引擎获取数据。

• MySQL使用为什么要分库分表

可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表. 这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗? 其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表属于一个非常核用的表:朋友关系表. 但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题. 这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基本不在可能.所以大项在使用中都会面监着分库分表的应用.

• MySQL半同步复制(Semisynchronous Replication)

MySQL5.5引入了半同步复制(Semi-synchronous Replication)，以下是对于半同步复制的认知和理解： 1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块，从库端支持半同步功能的数量至少一台；主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认)，这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。 2. 半同步与异步复制相比，进一步提高了数据完整性(不太理解为什么这么说)，保证了事务成功提交后，有两份记录被记录下来，一份在主库上，另一份至少在一个从库上。 3. 半同步复制在平衡性能与数据可靠性方面，采用了network group commit的方式来复制binlog。