对于MySQL把有的存储引擎都是把表结构的定义存放到.frm文件中。但对于Innodb表同时有一个内部的字典存放到表空间中。所以对于Innodb表不能单纯的移动.frm在不同的MySQL事例下。对于Innodb引擎的表，如果MySQL 删除相应的表或数据库，同时会删除相应的.frm及在表空间的相应的字典信息。在.frm文件只是用来定义表的结构，Innodb把数据和索引都存放到了表空间中。

    聚集索引和次要索引：

    每一个Innodb表都有一个聚集索引，这个聚信索引和行数据存在一起。

    可以用来做聚集索引的列：

如果有声明了主建(primary key)，则这个列可以做为表的主建。 如果没有声明主建，MySQL会用一个唯一索引(UNIQUE)而且是不为空的列做为主建，成为该表的聚信索引。 如果没声明主建，同时也没合适的唯一的索引，Innodb内部会产生一个隐藏的聚集索引:RowID。这个RowID在Innodb的多版本中曾提到过。这个RowID是在插入时产生，并且是自增的增加。所以也是按顺序增长存放。

    由于聚集索引和行数据存放一起(在同一个数据页中)，所以利用聚集索引访问数据行时，非常的快，同一个数据页在访问索引时，已经把页加载到Buffer中，在访问数据时，等于了一个顺序IO的访问（内存中完成）。大多数情况下索引和数据都不在一块（MyISAM，数据和索引存到不同的文件中），而聚集索引是有结构的通常是按顺序存放，同时和数据存放在一起，利用索引索引访问大表的数据可以节省许多IO。

    对于Innodb次要的索引会包含聚信索引，查询在使用次要索引时，找到聚集索引信息，然后利用聚集索引信息访问行。所以，如果聚集索引过长，会造成空间浪费严重。另外，如果对表或是区间进行Count操作的话，大多数情况较短的次要索引比基于聚集索引快。对于Innodb的聚集索引选择，尽量选择比较短的列做为聚集索引列，是一个好的设计习惯。

    索引的物理结构：

    Innodb的索引以B-tree的形式存到各个叶点上。索引叶点页的大小默认为16K，当有什么的索引插入叶点时，该叶点至少会保留1/16的空闲空间，用于将来该叶点的索引更新或是插入。

    对于顺序写入的索引（无论是递增或是递减，顺序的就行），索引叶点可以达到15/16满。如果是随机的索引写入行为，叶点只会达到1/2到15/16满。当叶点填充在1/2以下满，或是被删除到1/2下满时，Innodb会缩短索引树，试图释放该叶点，该叶点可以被继续写入数据。

设计中的Tips：

    因为Innodb表的数据是依赖于聚集索引顺序存放，同时聚集索引和数据一块存储，普通索引也需要存放一份聚集索引。所以对于聚集索引的设计尽量按顺序写入，必免数据分页，行迁移等对性能影响的现象。另外聚集索引要设计的尽可能短。从设计上必须锁的时间，大量随机IO的出现。

    如对于监控（或是股票类的信息）可以利用时间和类型构成聚集索引，让相关性高的数据尽可能位到一块。以便读取时可以利用顺序IO读取到相应的数据。最好的情况，相关性高的数据在一个Page上，这样读取的效果更好。基于Innodb聚集索引的特性，在设计上也需要考虑利用一下优势，必免其不好的一方面从而达到最佳性能。

相关文章

• 2008-11-18 — Innodb 索引结构了解 - Innodb Index Structure
• 2010-03-09 — InnoDB线程并发检查机制
• 2009-12-20 — Innodb如何使用内存
• 2009-12-20 — Innodb文件表空间结构
• 2009-12-12 — InnoDB的”替代品”：Percona XtraDB
• 2009-11-18 — Memory & MyISAM 引擎小注意！
• 2009-09-25 — Innodb表空间page size的选择
• 2009-09-13 — Mysql combine index
• 2009-09-03 — MySQL InnoDB性能调整的一点实践
• 2009-08-18 — 随机主键对InnoDB插入性能的影响

在新的MySQL线程调用Innodb接口前，Innodb会检查已经接受的请求线程数，如已经超过innodb_thread_concurrency设置的限制，则该请求线程会等待innodb_thread_sleep_delay微秒后尝试重新请求，如果第二次请求还是无法获得，则该线程会进入线程队列休眠。重试两次的机制是为了减少CPU的上下文切换的次数，以降低CPU消耗，这和Oracle中latch的spin机制是同样的道理。如果请求被Innodb接受，则会获得一个次数为innodb_concurrency_tickets(默认500次)的通行证，在次数用完之前，该线程重新请求时无须再进行前面所说innodb_thread_concurrency的检查。

上述检查逻辑在源码storage/innobase/srv/srv0srv.c(Innodb很多参数都可以在该文件中找到定义)的srv_conc_enter_innodb函数中，有兴趣的可以仔细阅读一下，代码比较浅显，不难理解。另外，如果是一个已经持有lock的线程，则通过调用srv_conc_force_enter_innodb函数可以无视该检查，这是为了避免线程长时间持有锁影响性能，且可能增加死锁的机率。除此之外，slave线程也是有无视检查直接通行的权限。

简单思考一下上述机制，可以得出一个初步的推论：在数据库并发请求较小的情况下，从性能上来说禁用检查机制应该是更好的，毕竟执行检查机制本身也需要加锁(Mutex)。当并发线程很高的情况下，则开启检查机制对性能更有利。至于具体innodb_thread_concurrency设置为多少，可能就需要在不同的条件下实际的做一下测试了，不同的硬件环境，不同的MySQL版本和Innodb版本，应该都会有一些区别。

源代码中对于innodb_thread_concurrency参数的注释如下：

/* The following controls how many threads we let inside InnoDB concurrently:
threads waiting for locks are not counted into the number because otherwise
we could get a deadlock. MySQL creates a thread for each user session, and
semaphore contention and convoy problems can occur withput this restriction.
Value 10 should be good if there are less than 4 processors + 4 disks in the
computer. Bigger computers need bigger values. Value 0 will disable the
concurrency check. */

ulong   srv_thread_concurrency  = 0;

因为检查机制需要Mutex保护(Mutex-based Model)，所以开启检查本身也有性能消耗，并且扩展性也会受到限制，在MySQL5.4版本中引入了一种新的机制（Timer-based Model），这里就不讨论了，有兴趣的可以参考这里(需要翻墙)，实际上XtraDB存储引擎里已经包含Timer-based Model，通过参数innodb_thread_concurrency_timer_based可以开启，默认为OFF。在MySQL5.4的srv0srv.c的源代码中的注释中，可以看到Google和Percona的版权声明，看来MySQL5.4中吸引了很多第三方的改进代码，值得期待。

相关文章

• 2010-03-09 — Innodb 表和索引结构
• 2009-12-20 — Innodb如何使用内存
• 2009-12-20 — Innodb文件表空间结构
• 2009-12-12 — InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 — Innodb表空间page size的选择
• 2009-09-03 — MySQL InnoDB性能调整的一点实践
• 2009-08-18 — 随机主键对InnoDB插入性能的影响
• 2009-08-18 — InnoDB之Dirty Page、Redo log
• 2009-08-04 — innodb相关参数
• 2009-08-04 — InnoDB insert性能拐点测试

1、Lost connection to MySQL server at ‘reading initial communication packet’：
这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大程度避免这个问题。

2、Lost connection to MySQL server at ‘reading authorization packet’：
从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题；然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请求。

3、Lost connection to MySQL server during query：
这个问题具备随机性，而淘宝MySQL的应用场景决定了我们无法多次备份数据以便重现问题。
然而我们注意到这个问题一般会在两种情况下会发生。一种是mysqldump **** | gzip ****；另外一种是mysqldump **** > /nfs-file
注意，不管是gzip还是nfs都有一种特点，那就是它们影响了mysqldump的速度。从这个角度思考，是不是mysqldump从MySQL接受数据包的速度不够快导致Lost connection to MySQL server during query错误呢？

为了定位到问题，我搭建了一个测试环境：
test@192.168.0.1：3306
CREATE TABLE `test` (
`id` bigint(20) NOT NULL auto_increment,
`b` varchar(2000) default NULL,
`c` varchar(2000) default NULL,
`d` varchar(2000) default NULL,
`e` varchar(2000) default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

insert into test(b,c,d,e) values (lpad(’a’,1900,’b’), lpad(’a’,1900,’b’), lpad(’a’,1900,’b’), lpad(’a’,1900,’b’));
多次复制数据使测试环境达到一定数据量。

192.168.0.2：
编写一个c++程序
#include <stdio.h>
#include <mysql.h>

using namespace std;

int main()
{
MYSQL conn;
MYSQL_RES *result;
MYSQL_ROW row;
my_bool reconnect = 0;

mysql_init(&conn);
mysql_options(&conn, MYSQL_OPT_RECONNECT, &reconnect);

if(!mysql_real_connect(&conn, “192.168.0.1″, “test”, “test”, “test”, 3306, NULL, 0))
{
fprintf(stderr, “Failed to connect to database: %s\n”, mysql_error(&conn));
exit(0);
}
else
{
fprintf(stdout, “Success to connect\n”);
}

mysql_query(&conn, “show variables like ‘%timeout%’”);
result = mysql_use_result(&conn);
while(row=mysql_fetch_row(result))
{
fprintf(stdout, “%-10s: %s\n”, row[0], row[1]);
}
mysql_free_result(result);
fprintf(stderr, “\n”);

mysql_query(&conn, “select SQL_NO_CACHE * from test.test”);
result = mysql_use_result(&conn);
while((row=mysql_fetch_row(result))!=NULL)
{
fprintf(stderr, “Error %d: %s\n”, mysql_errno(&conn), mysql_error(&conn));
fprintf(stdout, “%s\n”, row[0]);
sleep(100);
}
fprintf(stderr, “Error %d: %s\n”, mysql_errno(&conn), mysql_error(&conn));
mysql_free_result(result);
mysql_close(&conn);
return 1;
}

在这段代码里，sleep函数用来模拟NFS的网络延迟和gzip的运算时间。执行一段时间之后，Lost connection to MySQL server during query出现了，程序意外终止。在数据处理足够快的情况下，又会是怎样的结果？

将sleep的时间改为1，重新编译后发现程序能够完整跑完。根据《MySQL Timeout解析》上对net_write_timeout的解释，我们可以发现，mysqldump处理数据过慢（NFS、gzip引起）会导致MySQL主动断开连接，此时mysqldump就会报Lost connection to MySQL server during query错误。经过多次测试，确定这个错误是由于net_write_timeout设置过短引起。

相关文章

• 2009-08-11 — source sql文件报错
• 2009-06-07 — mysqldump 导出触发器遇到的问题
• 2009-02-23 — 改良版本mysqldump来备份MYSQL数据库
• 2008-10-24 — mysqldump的几个主要选项探究

先看一下比较常见的Timeout参数和相关解释：
connect_timeout
The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.
interactive_timeout
The number of seconds the server waits for activity on an interactive connection before closing it.
wait_timeout
The number of seconds the server waits for activity on a noninteractive connection before closing it.
net_read_timeout
The number of seconds to wait for more data from a connection before aborting the read.
net_write_timeout
The number of seconds to wait for a block to be written to a connection before aborting the write.

从以上解释可以看出，connect_timeout在获取连接阶段（authenticate）起作用，interactive_timeout和wait_timeout在连接空闲阶段（sleep）起作用，而net_read_timeout和net_write_timeout则是在连接繁忙阶段（query）起作用。

获取MySQL连接是多次握手的结果，除了用户名和密码的匹配校验外，还有IP->HOST->DNS->IP验证，任何一步都可能因为网络问题导致线程阻塞。为了防止线程浪费在不必要的校验等待上，超过connect_timeout的连接请求将会被拒绝。

即使没有网络问题，也不能允许客户端一直占用连接。对于保持sleep状态超过了wait_timeout（或interactive_timeout，取决于CLIENT_INTERACTIVE标志）的客户端，MySQL会主动断开连接。

即使连接没有处于sleep状态，即客户端忙于计算或者存储数据，MySQL也选择了有条件的等待。在数据包的分发过程中，客户端可能来不及响应（发送、接收、或者处理数据包太慢）。为了保证连接不被浪费在无尽的等待中，MySQL也会选择有条件（net_read_timeout和net_write_timeout）地主动断开连接。

这么多Timeout足以证明MySQL是多么乐于断开连接。而乐于断开连接的背后，主要是为了防止服务端共享资源被某客户端（mysql、mysqldump、页面程序等）一直占用。

相关文章

• 目前没有相关的文章

另外要说明的是，如果你是通过alter databases(schema) 命令更改的数据库默认属性，那么现有的表的默认字符集和排序规则不受影响。

通过创建数据库指定数据库的默认字符集和排序规则：

也可以通过alter database修改

相关文章

• 2009-07-15 — 数据库字符集修改
• 2008-12-15 — 调用存储过程时报错:Illegal mix of collations
• 2008-12-03 — 深入Mysql字符集设置
• 2008-09-21 — 如何更改MySQL的默认字符集
• 2008-09-21 — 小谈MySQL字符集
• 2008-09-18 — mysql连接通道中的字符集和校验规则
• 2008-09-18 — mysql字符集与校验规则的设置
• 2008-09-18 — mysql的字符集与校验规则概念小介

    译这个文章的目的：

    　　最近经常被问起Innodb是如何使用内存的。该问题早已被原MySQL公司的Vadim论证过。我这里译一下他的文章供大家参考。

    开始：

    　　这里有许多关于Innodb如何使用内存的问题。我这里将会以innodb启动时的分配情况做一个解释。一些重要的概念：

    　　NBLOCKS＝Innodb_buffer_pool有多个页(block)＝innodb_buffer_pool_size/16384(16k)

     　OS_THREADS= if ( innodb_buffer_pool_size >= 1000Mb) = 50000

     　　else if (innodb_buffer_pool_size >= 8Mb) = 10000

    　　 else = 1000 (该值只用在*nixes系统上，对于Windows有一点小的区别计算OS_THREADS)

    所以Innodb 使用的内存包括：

    　innodb_buffer_pool_size

     innodb_additional_mem_pool_size

     innodb_log_buffer_size

     adaptive index hash ,size (innodb buffer 索引管理区)= innodb_buffer_pool_size/64

     system dictionary hash,size(innodb内部字典区) = 6 * innodb_buffer_pool_size/512

     memory for sync_array,size(用于Innodb内部syncronzation的开销)=OS_THREAD * 512

     memory for os_event,size(用于innodb内存的syncronzation的开销)=OS_THREAD * 216

     memory for locking system(内存的锁管理系统),size = 5 * 4 *NBBLOCKS

     最终得到innodb内存使用的计算公式为：

     Innodb_buffer_pool_size + innodb_log_buffer_size + innodb_additional_mem_pool_size + 812/16384 * innodb_buffer_pool_size + OS_THREADS * 368

     对于812/16384 * Innodb_buffer_pool_size 可以简单的用 innodb_buffer_pool_size / 20　计算，

    对于OS_THREADS * 368　　

     OS_THREADS * 368 = 17.5 MB if innodb_buffer_pool_size > 1000MB

     OS_THREADS * 368 = 3.5 MB if innodb_buffer_pool_size > 8MB

    举一个例子：

    　　 如果你的innodb_buffer_pool_size有1500MB,innodb_additional_mem_pool_size =20 MB,innodb_log_buffer_size = 8M,

     　　Innodb 将会向系统申请内存为= 1500M + 20M + 8M + 1500/20 M +17.5 = 1620.5M

    　　根据以上的条件可以算出Innodb最根本最需要多少内存，这样对于服务器的内存使用也可以有一个规划了。

相关文章

• 2010-03-09 — Innodb 表和索引结构
• 2010-03-09 — InnoDB线程并发检查机制
• 2009-12-20 — Innodb文件表空间结构
• 2009-12-12 — InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 — Innodb表空间page size的选择
• 2009-09-03 — MySQL InnoDB性能调整的一点实践
• 2009-08-18 — 随机主键对InnoDB插入性能的影响
• 2009-08-18 — InnoDB之Dirty Page、Redo log
• 2009-08-04 — innodb相关参数
• 2009-08-04 — InnoDB insert性能拐点测试

    show variables like \’%sche%\’;

    将事件计划开启

    set global event_scheduler =1;

    创建存储过程test

     CREATE PROCEDURE test ()

     BEGIN

     update examinfo SET endtime = now() WHERE id = 14;

     END;

     创建event e_test

     create event if not exists e_test

     on schedule every 30 second

     on completion preserve

     do call test();

     每隔30秒将执行存储过程test,将当前时间更新到examinfo表中id=14的记录的endtime字段中去.

     关闭事件任务

     alter event e_test ON

     COMPLETION PRESERVE DISABLE;

     开户事件任务

     alter event e_test ON

     COMPLETION PRESERVE ENABLE;

     以上测试均成功,测试环境为mysql 5.4.2-beta-community mysql community server(GPL)

相关文章

• 目前没有相关的文章

     表空间是在配置文件中定义的几个文件简单的耦合起来，在使用中互不可少（少一个就面临DB完蛋的危险）。对于共享表空间无法确定表所在的表空间上。

     独立表空间可以做到每个表有自已的表空间（羞一下）。

     针对共享表空间，表空间中包括：回滚段,段（segment），区域（extent),数据页(page size)在表空间的体现为：

     表空间由默认16k的数据页面（page)组成，每64个连续的页面组成一个区域（extent,Oracle里熟悉的一个东东）。对于表空间的“文件(file)”在Innodb中被称为段(segment)。 回滚段(rollback segment）是一个特殊的例子，实际上rollback segment包含了多个段。对于Innodb表的索引都被分配成两个段：一个是为了 B-tree 的无叶结点(non-leaf nodes)，另一个是为了叶结点(leaf nodes)。

     这是为了达到包含数据的叶结点的更好的顺序(sequentiality for the leaf nodes)。

     当表空间中的一个段增长时，InnoDB 为它个别地分配最初的 32 个页面。之后 InnoDB 再分配段的整个区域(extents)。InnoDB 会以每次 4 个区域(extents)来增加一个大段以确保数据的良好顺序。

     表空间中的某些页面包含其它页面的位图(bitmaps)，所以在 InnoDB 表空间内的一些区域(extents)不能以一个整体分配给段，而只能作为个体页面。

     当发出一个查询 SHOW TABLE STATUS FROM … LIKE … 来询问表空间的剩余空间时，InnoDB 将报告表空间中所有空闲区域(extents)中确实可用的部分。InnoDB 通常会保留一些区域用于 clean-up 和其它的内部目的；这些保留的区域并不包含在剩余可用空间中。

     当从一个表中删除数据时，InnoDB 将收缩 B-tree 中相应的索引。这是依赖于释放个别的页面或区域(extents)以让其他用户使用剩余空间的删除模式。 移除(drop)一个表或删除所有记录可以保证释放空间给其他用户，但是删除记录行只有在事务回滚或 consistent read 后并不需要时才会被物理的移除

     对于独立表空间也是存一样的概念和行为，唯一区别就是每个表的数据存到指定的表空间中，rollback segment不和数据的segment在一个竞争。使用独立表空间的一个好处就是可以使数据分布相对于磁盘上更连续一点。

相关文章

• 2010-03-09 — Innodb 表和索引结构
• 2010-03-09 — InnoDB线程并发检查机制
• 2009-12-20 — Innodb如何使用内存
• 2009-12-12 — InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 — Innodb表空间page size的选择
• 2009-09-03 — MySQL InnoDB性能调整的一点实践
• 2009-08-18 — 随机主键对InnoDB插入性能的影响
• 2009-08-18 — InnoDB之Dirty Page、Redo log
• 2009-08-04 — innodb相关参数
• 2009-08-04 — InnoDB insert性能拐点测试

    如果是INNODB的话.其实是无法修改库名的.网上瞎咧咧的什么RENAME DATABASE或者ALTER DATABASE都是不行的

    一种方法是比较保守的.直接把老库的内容mysqldump到新库里面

    还有一种类似上面方法.先alter table 的存储引擎到MyISAM,然后改了库目录的名字,然后再改回来INNODB.

    最后一种方法还是比较好的.这边详细写一下.

    假设源库名是’srcdb’,目标库名是’trgdb’

    首先创建目标库

    create database trgdb;

    获取所有源库的表名

    use information_schema;

    select table_name from TABLES where TABLE_SCHEMA=’srcdb’;

    然后按照以下命令一个个修改

    rename table srcdb.[tablename] to trgdb.[tablename];

    一个个执行下来之后表就转到新的库里面了.

相关文章

• 目前没有相关的文章

XtraDB是Percona Team在InnoDB的基础上开发出来的一个更加强大的存储引擎，它百分百的兼容InnoDB，我们可以用XtraDB来替代为MySQL的发展做出历史性贡献的InnoDB，新的XtraDB引擎将具有更加强大的性能优势，以及良好的扩展性和一些新特性。

Percona于2008年12月16日正式对外公布Percona XtraDB存储引擎，当时版本为1.0.2-1。在09年有相继发布了release 3/4/5/8，目前最新的版本为Percona-XtraDB 1.0.4-8。

安装XtraDB存储引擎

XtraDB的安装有这么几种：一是现成的RPMS包安装，不过这些包仅限于x86_64位RedHat/CentOS 4/5系统下，而且MySQL的版本为5.1.30；还有就是通过整体编译MySQL源码包的安装,即将新的XtraDB引擎的代码整合到MySQL的源码中，进行重新编译。前面这两种都需要重新搭建MySQL数据库，例外还有一种，就是动态的将XtraDB加载进正在运行MySQL中，这个看上去很符合生产的要求。

下面我们就来介绍Linux系统下，源码包的安装方法，具体步骤如下：

1.下载MySQL的源码安装包。http://dev.mysql.com/downloads/mysql/5.1.html#source

2.下载Percona XtraDB的源码安装包。https://launchpad.net/percona-xtradb/+download

3.编译安装MySQL

shell>tar -xvf mysql-5.1.35.tar.gz

shell>cd mysql-5.1.35/storage

shell>tar -xvf percona-xtradb-1.0.4-8.tar.gz

shell>rm -rf innobase

shell>mv percona-xtradb-1.0.4-8 innobase

shell>cd ..

shell>./configure -prefix=/usr/local/mysql -with-plugins=innobase && make && make install

shell> cp support-files/my-medium.cnf /etc/my.cnf

shell> cd /usr/local/mysql

shell> chown -R mysql.mysql .

shell> bin/mysql_install_db -user=mysql

shell> chown -R root .

shell> chown -R mysql var

shell> bin/mysqld_safe -user=mysql &

4.验证XtraDB引擎的100%兼容Innodb。

shell> mysql -uroot -p < eiken_uat_backup.090803230101  (将生产数据库导入新的MySQL)

mysql> show create table user_role\G

*************************** 1. row ***************************

       Table: user_role

Create Table: CREATE TABLE `user_role` (

  `user_name` varchar(100) NOT NULL,

  `role_name` varchar(25) NOT NULL,

…omit….

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)

(经测试，所有应用一切正常。)

mysql> create table xtradb_tb(id int(3),engine_name char(120)) engine=innodb; （创建一个使用XtraDB引擎的表）

Query OK, 0 rows affected (0.00 sec)

mysql> show create table xtradb_tb\G

*************************** 1. row ***************************

       Table: xtradb_tb

Create Table: CREATE TABLE `xtradb_tb` (

  `id` int(3) DEFAULT NULL,

  `engine_name` char(120) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)

（NOTE：如果你要使用XtraDB这个引擎，engine的值依然要设置成InnoDB。）

比较

最后，我们简要比较一下XtraDB与InnoDB之间都有哪些变化。分别连上配有不同引擎的数据库服务。比较如下：

1.INFORMATION_SCHEMA中的表数量发生明显变化。

XtraDB ：42个（增加了13项INNODB开头的表和一个XTRADB_ENHANCEMENTS表，改表中记录逐一介绍了新的XtraDB对InnoDB所做的各项改进）

InnoDB ：28个

2. SHOW INNODB STATUS命令的输出内容的增加。

其中，BUFFER POOL AND MEMORY的内容变得更加丰富。

同时，在输出中，我们还会发现，XtraDB在线程的投入上也有很大提高，在InnoDB中FILE I/O的线程仅为4个，而在XtraDB中你会发现为10个，分别是读、写的线程数都各自增加为4个，这对于性能会有很大提升。

P.S.: 其实，第一次听到InnoDB的替代引擎，实在最近的一次面试的时候，当时，一听傻了，在想“InnoDB”什么时候除了替代品啦，我真的太孤陋寡闻了（Hiro听到后一定有要鄙视我了，LOL:>）。后来，查了一下，是真地——Percona XtraDB，出来了！

相关文章

• 2010-03-09 — Innodb 表和索引结构
• 2010-03-09 — InnoDB线程并发检查机制
• 2009-12-20 — Innodb如何使用内存
• 2009-12-20 — Innodb文件表空间结构
• 2009-09-25 — Innodb表空间page size的选择
• 2009-09-03 — MySQL InnoDB性能调整的一点实践
• 2009-08-18 — 随机主键对InnoDB插入性能的影响
• 2009-08-18 — InnoDB之Dirty Page、Redo log
• 2009-08-04 — innodb相关参数
• 2009-08-04 — InnoDB insert性能拐点测试

    如果用来分区的字段和主键不是同一个，则不能分区见很早前的一篇译文mysql 5.1新功能 －－ 按日期分区，如果查询条件中没有正确利用到分区的字段，那么partition的效果为零mysql 5.1.31之前的partition功能有较大的bug，会导致自增字段不能正常自增，怎么个不正常法？auto_increment值会非正常增长，突然比当前的最大id小很多，插入数据时导致duplicate key错误。

    这些问题都能凑合着对付过去，但是partition功能和auto_increment似乎是天生的敌人。从使用习惯上来说，我们会把auto_increment字段设置为主键，这个字段要是unique的才比较稳妥，这个情况下如果希望用其它字段来进行分区的话，几乎就成了不可能的任务。以这张表为例：

    这个时候试图以uid进行分区会怎么样？是以怎样的惨淡结局收场？变通的办法是对自增字段做一些调整，从mysql的手册来看，自增字段不一定要设置成主键，仅仅是普通的index也可以，那么把表结构换成下面这个样子，就可以分区成功。

    我在实际环境中有一张表达到了几亿条数据，如果要用时下流行的sharding策略，必须在代码上做一些改动，当时偷了点懒直接使用partition功能，用了大半年倒也相安无事。只是分区表占用内存相当的大，如果有其它的表经常出现慢查询耗费服务器资源，那么雪崩效应就出现了，所有的查询都会堵塞变得非常慢。

相关文章

• 目前没有相关的文章

进攻：

假设你的程序里有类似下面内容的脚本：

$sql = “SELECT id, title, content FROM articles WHERE id = {$_GET['id']}”;

正常访问时其URL如下：

/articles.php?id=123

当黑客想判断是否存在SQL Injection漏洞时，最常用的方式就是在整形ID后面加个单引号：

/articles.php?id=123′

由于我们没有过滤$_GET['id']参数，所以必然会报错，可能会是类似下面的信息：

supplied argument is not a valid MySQL result resource in …

这些信息就足以说明脚本存在漏洞了，我们可以再耍点手段：

/articles.php?id=0 union select 1,2,3

之所以select 1,2,3是因为union要求两边的字段数一致，前面是id,title,content三个字段，后面1,2,3也是三个，所以不会报语法错误，还有设置id=0是一条不存在的记录，那么查询的结果就是1,2,3，反映到网页上，原本显示id的地方会显示1，显示title的地方会显示2，显示content的地方会显示3。

至于如何继续利用，还要看magic_quotes_gpc的设置：

当magic_quotes_gpc为off时：

/articles.php?id=0 union select 1,2,load_file(’/etc/passwd’)

如此一来，/etc/passwd文件的内容就会显示在原本显示content的地方。

当magic_quotes_gpc为on时：

此时如果直接使用load_file(’/etc/passwd’)就无效了，因为单引号被转义了，但是还有办法：

/articles.php?id=0 union select 1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100))

其中的数字就是/etc/passwd字符串的ASCII，除此以为，还可以使用字符串的十六进制：

/articles.php?id=0 union select 1,2,load_file(0×2f6574632f706173737764)

这里仅仅说了数字型参数的几种攻击手段，属于冰山一角，字符型参数等攻击看我文章后面的文档链接。

防守：

网络上有一些类似SQL Injection Firewall的软件可供使用，比如说GreenSQL，如果网站已经开始遭受SQL Injection攻击，那么使用这样的快捷工具往往会救你一命，不过这样的软件在架构上属于一个Proxy的角色，多半会影响网站并发性能，所以在选择与否这个问题上最好视客观条件来慎重决定。很多时候专业的软件并不是必须的，还有很多轻量级解决方案，下面演示一下如何使用awk来检测可能的漏洞。

创建detect_sql_injection.awk脚本，内容如下（如果要拷贝一下内容的话记得不要包括行号）：

01 #!/bin/gawk -f
02
03 /\$_(GET|POST|COOKIE|REQUEST)\s*\[/ {
04     IGNORECASE = 1
05     if (match($0, /\$.*(sql|query)/)) {
06         IGNORECASE = 0
07         output()
08         next
09     }
10 }
11
12 function output()
13 {
14     $1 = $1
15     print "CRUD: " $0 "\nFILE: " FILENAME "\nLINE: " FNR "\n"
16 }

此脚本可匹配出类似如下的问题代码，想要扩展匹配模式也容易，只要照猫画虎写if match语句即可。

1：$sql = "SELECT * FROM users WHERE username = '{$_POST['username']}’”;
2：$res = mysql_query(”SELECT * FROM users WHERE username = ‘{$_POST['username']}’”);

使用前别忘了先chmod +x detect_sql_injection.awk，有两种调用方法：

1：./detect_sql_injection.awk /path/to/php/script/file
2：find /path/to/php/script/directory -name “*.php” | xargs ./detect_sql_injection.awk

会把有问题的代码信息显示出来，样子如下：

CRUD: $sql = “SELECT * FROM users WHERE username = ‘{$_POST['username']}’”;
FILE: /path/to/file.php
LINE: 123

现实环境中有很多应用这个脚本的方法，比如说通过CRON定期扫描程序源文件，或者在SVN提交时通过钩子方法自动匹配。

使用专业工具也好，检测脚本亦罢，都是被动的防守，问题的根本始终取决于在程序员头脑里是否有必要的安全意识，下面是一些必须要牢记的准则：

1：数字型参数使用类似intval，floatval这样的方法强制过滤。
2：字符串型参数使用类似mysql_real_escape_string这样的方法强制过滤，并且要注意字符集。
3：最好抛弃mysql_query这样的拼接SQL查询方式，尽可能使用PDO的prepare绑定方式。
4：使用rewrite技术隐藏真实脚本及参数的信息，通过rewrite正则也能过滤可疑的参数。
5：关闭错误提示，不给攻击者提供敏感信息：display_errors=off。
6：以日志的方式记录错误信息：log_errors=on和error_log=filename，定期排查，Web日志最好也查。
7：不要用具有FILE权限的账号（比如root）连接MySQL，这样就没有权限使用load_file等函数。
8：……

网站安全其实并不复杂，总结出来就是一句话：过滤输入，转义输出。其中，我们上面一直讨论的SQL Injection问题就属于过滤输入问题，至于转义输出问题，其代表是Cross-site scripting，但它不属于本文的范畴，就不多说了。

文档：

addslashes() Versus mysql_real_escape_string()
SQL Injection with MySQL
Advanced SQL Injection with MySQL
MySQL注入中导出字段内容的研究——通过注入导出WebShell

相关文章

• 目前没有相关的文章

背景：

假设这么一个情况，你是某公司mysql-DBA，某日突然公司数据库中的所有被人为删了。

尽管有数据备份，但是因服务停止而造成的损失上千万，现在公司需要查出那个做删除操作的人。

但是拥有数据库操作权限的人很多，如何排查，证据又在哪？

是不是觉得无能为力？

mysql本身并没有操作审计的功能，那是不是意味着遇到这种情况只能自认倒霉呢？

本文就将讨论一种简单易行的，用于mysql访问审计的思路。

概述：

其实mysql本身已经提供了详细的sql执行记录–general log ，但是开启它有以下几个缺点

无论sql有无语法错误，只要执行了就会记录，导致记录大量无用信息，后期的筛选有难度。

sql并发量很大时，log的记录会对io造成一定的印象，是数据库效率降低。

日志文件很容易快速膨胀，不妥善处理会对磁盘空间造成一定影响。

本文观点：

使用init-connect + binlog的方法进行mysql的操作审计。

由于mysql binlog记录了所有对数据库长生实际修改的sql语句，及其执行时间，和connection_id但是却没有记录connection_id对应的详细用户信息。

因此本文将通过init-connect，在每次连接的初始化阶段，记录下这个连接的用户，和connection_id信息。

在后期审计进行行为追踪时，根据binlog记录的行为及对应的connection-id 结合 之前连接日志记录 进行分析，得出最后的结论。

正文：

1. 设置init-connect

1.1 创建用于存放连接日志的数据库和表

create database accesslog;

CREATE TABLE accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))

1.2 创建用户权限

可用现成的root用户用于信息的读取

grant read on accesslog.* to root@localhost identified by ‘password’;

如果存在具有to *.* 权限的用户需要进行限制。

1.3 设置init-connect

在[mysqld]下添加以下设置：

init-connect=’insert into accesslog.accesslog values(connection_id(),user(),current_user(),now());’

log-bin

1.4 重启数据库生效

shell> service mysqld restart

2. 记录追踪

2.1 thread_id确认

假设想知道在2009年11月25日，上午9点多的时候，是谁吧test.dummy这个表给删了。可以用以下语句定位

mysqlbinlog –start-datetime=’2009-11-25 09:00:00′ –stop-datetime=’2009-11-25 09:00:00′  binlog.xxxx | grep ‘dummy’ -B 5

会得到如下结果(可见thread_id为5)：

# at 300777

#091124 16:54:00 server id 10  end_log_pos 301396       Query   thread_id=5     exec_time=0     error_code=0

SET TIMESTAMP=1259052840;

drop table test.dummy;

2.2 用户确认

thread_id 确认以后，找到元凶就只是一条sql语句的问题了。

select * from accesslog.accesslog where conn_id=5 ;

就能发现是testuser2@localhost干的了。

+——+——————————-+——————————-+—————————–+

| id   | time                        | localname              | matchname          |

+——+——————————-+——————————-+—————————–+

|   5  | 2009-11-25 10:57:39 | testuser2@localhost | testuser2@%        |

+——+——————————-+——————————-+—————————–+

3. Q&A

Q：使用init-connect会影响服务器性能吗？

A：理论上，只会在用户每次连接时往数据库里插入一条记录，不会对数据库产生很大影响。除非连接频率非常高（当然，这个时候需要注意的就是如何进行连接复用和控制，而非是不是要用这种方法的问题了）

Q：access-log表如何维护?

A: 由于是一个log系统，推荐使用archive存储引擎，有利于数据厄压缩存放。如果数据库连接数量很大的话，建议一定时间做一次数据导出，然后清表。

Q：表有其他用途么？

A：有！access-log表当然不只用于审计，当然也可以用于对于数据库连接的情况进行数据分析，例如每日连接数分布图等等，只有想不到没有做不到。

Q：会有遗漏的记录吗？

A：会的，init-connect 是不会在super用户登录时执行的。所以access-log里不会有数据库超级用户的记录，这也是为什么我们不主张多个超级用户，并且多人使用的原因。

相关文章

• 2009-09-07 — 使用mysqldumpslow和mysqlsla分析mysql慢查询日志
• 2009-08-05 — MySQL的日志文件
• 2009-04-08 — 利用binlog来恢复数据库
• 2009-02-26 — mysql的日志
• 2008-11-18 — 删除MYSQL BIN-LOG 日志
• 2008-11-12 — MySQL在切换binlog时会阻塞更新

# /usr/local/mysql/bin/mysqld -V
/usr/local/mysql/bin/mysqld  Ver 5.0.83-log for pc-linux-gnu on i686 (MySQL Community Server (GPL))

版本号是5.0.83，大于5.0.37，感觉应该可以使用profile功能，可是：

mysql> set profiling = 1;
ERROR 1193 (HY000): Unknown system variable ‘profiling’

出人意料，竟然无法使用profile功能。接着试试别的命令：

mysql> show profiles;
ERROR 1289 (HY000): The ‘SHOW PROFILES’ feature is disabled; you need MySQL built with ‘enable-profiling’ to have it working

这次的错误信息相对而言更明确了，说编译时没有激活enable-profiling选项。确认一下目前的编译参数：

# cat /usr/local/mysql/bin/mysqlbug | grep CONFIGURE_LINE
CONFIGURE_LINE=”./configure  ‘–prefix=/usr/local/mysql’ ‘–localstatedir=/usr/local/mysql/data’ ‘–libexecdir=/usr/local/mysql/bin’ ‘–with-comment=MySQL Community Server (GPL)’ ‘–with-server-suffix=’ ‘–enable-thread-safe-client’ ‘–enable-local-infile’ ‘–enable-assembler’ ‘–with-pic’ ‘–with-fast-mutexes’ ‘–with-client-ldflags=-static’ ‘–with-mysqld-ldflags=-static’ ‘–with-zlib-dir=bundled’ ‘–with-big-tables’ ‘–with-yassl’ ‘–with-readline’ ‘–with-innodb’ ‘–with-ndbcluster’ ‘–with-archive-storage-engine’ ‘–with-blackhole-storage-engine’ ‘–with-csv-storage-engine’ ‘–without-example-storage-engine’ ‘–with-federated-storage-engine’ ‘–with-extra-charsets=all’ ‘CC=ccache /usr/local/gcc-4.3.2/bin/gcc -static-libgcc’ ‘CFLAGS=-g -O3 -march=i686′ ‘CXX=ccache /usr/local/gcc-4.3.2/bin/gcc -static-libgcc’ ‘CXXFLAGS=-g -O3 -march=i686′”

确实没enable-profiling选项，不过别以为简单加上这个选项之后重新编译一次就行了，实际上如果想编译成功，还得同时确保存在enable-community-features选项，可参阅官方文档。如果觉得记这些编译命令太烦，那就使用新版的MySQL吧，从5.1.28版本开始，这些选项缺省就是激活的。

补充点知识，查看nginx，apache，mysql，php的编译参数（假设都安装在/usr/local目录）：

查看nginx编译参数：/usr/local/nginx/sbin/nginx -V
查看apache编译参数：cat /usr/local/apache/build/config.nice
查看mysql编译参数：cat /usr/local/mysql/bin/mysqlbug | grep CONFIGURE_LINE
查看php编译参数：/usr/local/php/bin/php -i | grep configure

相关文章

• 2009-08-12 — Unknown system variable ‘profiling’

我们来小解决下。
示例表结构：
create table t1_memory (
id int unsigned not null auto_increment primary key,
a1 decimal(15,12),
a2 decimal(15,12),
remark varchar(200) not null,
key idx_u1 (a1,a2)
) engine memory;

create table t1_myisam (
id int unsigned not null auto_increment primary key,
a1 decimal(15,12),
a2 decimal(15,12),
remark varchar(200) not null,
key idx_u1 (a1,a2)
) engine myisam;
示例SQL语句：
select * from t1_memory where a1>110 and a1<111 and a2>23 and a2<24;
select * from t1_myisam where a1>110 and a1<111 and a2>23 and a2<24;

语句执行计划：
explain
select * from t1_memory where a1>110 and a1<111 and a2>23 and a2<24;

相关文章

• 2009-07-15 — memory型表支持Hash索引
• 2008-11-18 — MySQL MyIsam 存储引擎索引长度限制测试记录
• 2008-10-24 — MySQL MyIsam 存储引擎索引长度限制测试记录
• 2010-03-09 — Innodb 表和索引结构
• 2009-09-13 — Mysql combine index
• 2009-07-17 — 查看索引使用情况
• 2009-07-13 — MyISAM和InnoDB的插入性能测试
• 2009-07-13 — Memory存储引擎表大小限制
• 2009-06-30 — mysql索引简单介绍
• 2009-05-01 — mysql索引的一个技巧

相关文章

• 目前没有相关的文章

从名字上可以得知UDF（user define function)为用户自定义函数。UDF在一定程度上可以使得普通用户定制自己的MySQL函数库，减少对内建函数的依赖。UDF 的功能还是非常强大的。

各类技术人员都可以开发相应的UDF。

管理员可以开发一些与系统交互的UDF。而开发人员可将常用功能用UDF替代存储函数，这样可以大幅提高执行速度和效率。

这篇BLOG的目的想给希望编写UDF的读者提供一些帮助，但读者应该根据自己的需要添加某些具体函数。

现在直入话题，MySQL手册上确实提供了有关MySQL UDF的一些规则。读者可以参考链接。

咱们分4步骤创建一个UDF：

1. 编写代码
2. 编译
3. 安装
4. 使用

下面给出一个简单的UDF。其作用就是往error日志里面写入语句。为了做这个实验，我们将使用如下平台：

• OS：OpenSolaris，
• DB：MySQL 5.1.39
• C compiler: Sun C
  

实例代码如下：

编写完毕代码后，需要将源代码编译成动态库.so文件。随后将动态库拷贝到MySQL安装目录的lib/plugin下。（在那里我们还可以找到Innodb的动态库文件）

根据你使用的OS、MySQL等环境。可能有所出入。在本实验中，使用如下

cc -I/user/local/mysql/include -shared -o mysqlsystems_udf_log.so mysqlsystems_udf_log.c

下图是安装和使用的过程：

查看MySQL的error日志：

网友可以看到，在error log第22号，出现了我们输入的 hello world字样。

相关文章

• 目前没有相关的文章

CREATE TABLE IF NOT EXISTS `categories` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(15) NOT NULL,
`created` datetime NOT NULL,
PRIMARY KEY (`id`)
);

CREATE TABLE IF NOT EXISTS `posts` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`category_id` int(10) unsigned NOT NULL,
`title` varchar(100) NOT NULL,
`content` varchar(200) NOT NULL,
`created` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `category_id` (`category_id`)
);

先注意一下每个表的索引情况，以后会用到，记得随便插入一点测试数据，不用太多，但怎么也得两行以上，然后执行以下SQL：

EXPLAIN SELECT *
FROM posts
LEFT JOIN categories ON posts.category_id = categories.id
WHERE categories.id = ‘一个已经存在的ID’
ORDER BY posts.created DESC

结果如下所示：

table      key         Extra
categories PRIMARY     Using filesort
posts      category_id Using where

在explain的结果中，第一行表示的表就是主表，所以说在此查询里categories是主表，而在我们的经验里，LEFT JOIN查询里，左表（posts表）才应该是主表，这产生一个根本的矛盾，MySQL之所以这样处理，是因为在我们的WHERE部分，查询条件是按照categories表的字段来进行筛选的，而恰恰categories表存在合适的索引，所以在查询时把categories表作为主表更有利于缩小结果集。

那explain结果中的Using filesort又是为什么呢？这是因为主表是categories表，从表是posts表，而我们使用从表的字段去ORDER BY，这通常不是一个好选择，最好改成主表字段，如果鉴于需求所限，无法改成主表的字段，那么可以尝试添加如下索引：

ALTER TABLE `posts` ADD INDEX ( `category_id` , `created` );

再运行SQL时就不会有Using filesort了，这是因为主表categories在通过category_id连接从表posts时，可以进而通过索引直接得到排序后的posts结果。

主观上一旦搞错了主表，可能怎么调整索引都得不到高效的SQL，所以在写SQL时，比如说在写LEFT JOIN查询时，如果希望左表是主表，那么就要保证在WHERE语句里的查询条件尽可能多的使用左表字段，进而，一旦确定了主表，也最好只通过主表字段去ORDER BY。

相关文章

• 2009-04-14 — MySql 随机读取数据
• 2008-12-05 — MySQL 中 Join 的基本实现原理

    早上在笔记本上测试了一下, 以生成Insert语句的方式, 从Oracle到MySQL迁移数据的速度. 对于MySQL来讲, 是不是绑定变量并不重要, 在MySQL的客户端编程中, 并没有绑定变量的概念, 这是因为MySQL并没有Oracle中类似的共享池, 而是由每个连接进程自行去解释SQL并执行.

    写了一个Windows上的批处理脚本, 用SQLULDR2从Oracle中查询数据, 并生成MySQL的Insert脚本, 用管道输入到MySQL中去执行.

@echo off
echo %TIME%
sqluldr2 … table=emp_his format=mysql quote=0×27 escape=0×53 null=null file=- | mysql test
echo %TIME%

    首先在MyISAM下测试, 先将表改成MyISAM方式存贮.

mysql> alter table emp_his engine= myisam;
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

    进行数据装载测试, 可以看出还是很快的.

D:\mysql-5.0.84-win32\bin>runload.bat
7:12:28.10
7:12:41.87

    查一下总共迁移的记录数.

mysql> select count(*) from emp_his;
+———-+
| count(*) |
+———-+
|  951308 |
+———-+
1 row in set (0.00 sec)

    接下来在Innodb下测试, 将表改成Innodb方式存贮.

mysql> alter table emp_his engine= innodb;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

    进行数据装载测试, 可以看出比MyISAM要慢不少.

D:\mysql-5.0.84-win32\bin>runload.bat
7:09:34.85
7:10:06.15

    查一下总共迁移的记录数.

mysql> select count(*) from emp_his;
+———-+
| count(*) |
+———-+
|  951308 |
+———-+
1 row in set (2.11 sec)

    在MySQL中, 将同样的表从MyISAM转到Innodb, 需要多少时间?

mysql> alter table emp_his engine= innodb;
Query OK, 951308 rows affected (16.67 sec)
Records: 951308  Duplicates: 0  Warnings: 0

    对于在笔记本上测试的这个结果, 个人是相当满意的, 测试的表有8个字段, 差不多等于平均数.

相关文章

• 2008-12-18 — InnoDB数据表空间文件平滑迁移

相关文章

• 目前没有相关的文章