MySql服务器的后台管理程序，要想使用客户端程序，该程序必须运行，因为客户端通过连接服务器来访问数据库。下面让我们以服务器的系统变量和状态变量为根据，优化我们的MySql数据库服务。 在这之前，我们需要掌握以下方法： 查看MySql状态及变量的方法： Mysql> show status —...

【服务器】  【mysql】  【innodb】  【线程】  【数据库】  【配置】   …

mysql5.6 alter table 与 Waiting for table metadata lock

上周在搞INSERT INTO … SELECT测试的时候，偶然发现一个奇怪的情况：
在insert into t select * from share 运行时， 同时执行alter table t add index(play_count)，
alter table语句会Waiting for table metadata lock， 直到insert into … select 语句结束。

      mysql [localhost] {msandbox} (spc) > SHOW processlist;
+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+
| Id | USER     | Host      | db   | Command | TIME | State                           | Info                                |
+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+
|  5 | msandbox | localhost | spc  | Query   |    8 | Waiting FOR TABLE metadata LOCK | ALTER TABLE t ADD INDEX(play_count) |
|  8 | …

INSERT INTO … SELECT 的锁

1) 起因

半个月之前，有个小伙子问我：INSERT INTO … SELECT * FROM tbl 会不会锁定表tbl，
我用屁股想了想， innodb做select操作，没必要锁表， 而且随手做了个测试：

在三个SESSION中依次快速运行下面的SQL语句：
SESSION 1:
###share_id为自增主键。
mysql [localhost] {msandbox} (spc) > INSERT INTO t SELECT * FROM share ORDER BY share_id ASC; 
Query OK, 135202 ROWS affected (15.30 sec)
Records: 135202  Duplicates: 0  Warnings: 0
 
SESSION 2:
mysql [localhost] {msandbox} (spc) > INSERT INTO share SET title='aaaaaaa'; UPDATE share SET play_count=play_count+1 ; 
Query OK, 1 ROW affected (0.06 sec)
 
Query OK, 135202 ROWS affected (29.75 sec)
ROWS matched: 135202  Changed: 135202  Warnings: 0
 
SESSION 3:
mysql [localhost] {msandbox} (information_schema) > SHOW processlist; …

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

数据库表设计这块学问比较多，我这里单从互联网角度出发同时结合Innodb的特性给出一些设计方法供大家参考。本文构建大概分两分部分:Innodb的特性及设计中如何利用这种特性。

Innodb特性：

• Innodb是索引聚集表， 存储结构是BTREE
• Innodb的表的数据存储是有顺序的，默认是以主建排序，主建即是数据本身，不单独存放。
• 如果没有主建,Innodb以第一个唯一索引排序，如果连唯一索引也没，Innodb内部会产生一个6字节的字段排序(这个也是性能杀手，所以对这块如果不想花太多时间去想这个事，就添加一个自增的列无业务意义做为主建即可) …

mysql Innodb auto_increment 字段的又一个奇怪问题

2013年才过去一个多月，我已经被颠覆过无数次了，今天又看到一个奇怪的问题：
我们都知道，在show create table 的时候:

mysql> SHOW CREATE TABLE tasks;
------------------------------------------------------+
| tasks | CREATE TABLE `tasks` (
  `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  `task` VARCHAR(30) DEFAULT NULL,
  `assignee` VARCHAR(30) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8

AUTO_INCREMENT=3表示下一次insert操作时，id的值将为3。 然后将一直增大下去。
所以它才被称作自增字段嘛。

可是您见过，这个AUTO_INCREMENT越变越小的时候么？

mysql> USE test;
DATABASE changed
mysql> 
mysql> CREATE TABLE `tasks` (
    -> …

之前和团队的同学一起翻译了部分InnoDB Plugin 1.0的手册，但是一直没有最终完稿。

利用周末的时间，我把剩下来的几章翻译完成并放到公司官方网站，希望大家一起来审阅一下。

这里也非常感谢彭立勋，胡中泉，陈良允同学。彭立勋主要翻译完成了1-7章，胡中泉，陈良允对文档进行了审阅。这些翻译文档也是取得了这些同学的同意才发表在公司博客网站的。

下面列出所有翻译文档的链接，请各位大牛批评指正(请直接在沃趣科技博客中评论)：

第一章：InnoDB Plugin简介
第二章：在InnoDB存储引擎下快速创建索引
…

问题背景 今天，看到Twitter的DBA团队发布了其最新的MySQL分支：Changes in Twitter MySQL 5.5.28.t9，此分支最重要的一个改进，就是修复了MySQL 的Bug #67718：InnoDB drastically under-fills pages in certain conditions。关于此Bug的详细描述，以及如何重现此问题，可以阅读以上的Bug链接，以下简单描述下此Bug对应的问题：   InnoDB的索引分裂策略，在特定的情况下，索引页面的分裂存在问题，导致每个分裂出来的页面，仅仅存储一条记录，页面的空间利用率极低。   此Bug引起了我的兴趣，因此准备跟大家简单聊聊B+树索引的结构、B+树的分裂、B+树分裂操作的优化、Bug #67718的成因，以及个人对如何修复此Bug的一些建议等。   B+树索引结构 …

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

对于数据库来讲大多瓶颈都出现在IO问题上，所以现在SSD类的设备也才能大行其道。那数据库的IO这块有什么可以优化的吗？ 我这里大致谈一下我的看法，希望能达到一个抛砖引玉的效果。
这里谈一下数据库本身的配置方面
具体如下：
配置方面对于IO优化的原则：尽可能能缓存，减少读对数据库的随机IO的请求；同时减少写的随机IO的随时发生，利用各种buffer去缓存。下面来看一下这块的参数：

• innodb_buffer_pool_size : …

  本期PPT分享内容：   InnoDB 日志/回滚段/崩溃恢复的实现详解。第一期分享的内容，是InnoDB与Oracle的Buffer Pool实现对比。而本期，让我们暂时告别Oracle，将心思完全放在InnoDB引擎上。本期的分享，将详细介绍如下内容： 一、InnoDB的日志相关内容：InnoDB有哪些日志？InnoDB的DML操作，会如何记录日志？为何不同的Update操作，性能上会有较大的不同？ 二、InnoDB的Redo详解：InnoDB Redo日志的种类？Mini-Transaction是什么？InnoDB的Log Buffer，Log Block的结构是怎样的？如何通过LSN计算对应的日志文件位置？ 三、InnoDB的Undo详解：InnoDB的回滚段结构是如何组织的？回滚段页面有哪些类型？事务与回滚段是如何交互的？事务提交、回滚、Purge的操作，分别如何进行？ …

InnoDB Adaptive Hash Index调研总结 #InnoDB Adaptive Hash Index# 定义 维护索引叶页面中所有记录的索引键值(或键值前缀)到索引叶页面位置的Hash映射关系，能够根据索引键值(前缀)快速定位到叶页面满足条件记录的Offset，减少了B+树Search Path的代价，将B+树从Root页面至Leaf页面的路径定位，优化为Hash Index的快速查询。   #InnoDB Adaptive Hash Index# 使用 Adaptive Hash Index是针对B+树Search Path的优化，因此所有会涉及到Search Path的操作，均可使用此Hash索引进行优化，这些可优化的操作包括：Unique Scan/Range Scan(Locate First Key Page)/Insert/Delete/Purge等等，几乎涵盖InnoDB所有的操作类型。   #InnoDB Adaptive Hash Index# 维护 …