分类目录归档:MySQL

MySQL性能优化的最佳20+条经验

2009年11月27日

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情。当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能。这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库。希望下面的这些优化技巧对你有用。

1. 为查询缓存优化你的查询

大多数的MySQL服务器都开启了查询缓存。这是提高性最有效的方法之一,而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候,这些查询结果会被放到一个缓存中,这样,后续的相同的查询就不用操作表而直接访问缓存结果了。

这里最主要的问题是,对于程序员来说,这个事情是很容易被忽略的。因为,我们某些查询语句会让MySQL不使用缓存。请看下面的示例:

// 查询缓存不开启
$r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()");

// 开启查询缓存
$today = date("Y-m-d");
$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

 

上面两条SQL语句的差别就是 CURDATE() ,MySQL的查询缓存对这个函数不起作用。所以,像 NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存,因为这些函数的返回是会不定的易变的。所以,你所需要的就是用一个变量来代替MySQL的函数,从而开启缓存。

 

2. EXPLAIN 你的 SELECT 查询

使用 EXPLAIN 关键字可以让你知道MySQL是如何处理你的SQL语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈。

EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的,你的数据表是如何被搜索和排序的……等等,等等。

挑一个你的SELECT语句(推荐挑选那个最复杂的,有多表联接的),把关键字EXPLAIN加到前面。你可以使用phpmyadmin来做这个事。然后,你会看到一张表格。下面的这个示例中,我们忘记加上了group_id索引,并且有表联接:

当我们为 group_id 字段加上索引后:

我们可以看到,前一个结果显示搜索了 7883 行,而后一个只是搜索了两个表的 9 和 16 行。查看rows列可以让我们找到潜在的性能问题。

3. 当只要一行数据时使用 LIMIT 1

当你查询表的有些时候,你已经知道结果只会有一条结果,但因为你可能需要去fetch游标,或是你也许会去检查返回的记录数。

在这种情况下,加上 LIMIT 1 可以增加性能。这样一样,MySQL数据库引擎会在找到一条数据后停止搜索,而不是继续往后查少下一条符合记录的数据。

下面的示例,只是为了找一下是否有“中国”的用户,很明显,后面的会比前面的更有效率。(请注意,第一条中是Select *,第二条是Select 1)

// 没有效率的:
$r = mysql_query("SELECT * FROM user WHERE country = 'China'");
if (mysql_num_rows($r) > 0) {
    // ...
}

// 有效率的:
$r = mysql_query("SELECT 1 FROM user WHERE country = 'China' LIMIT 1");
if (mysql_num_rows($r) > 0) {
    // ...
}

 

4. 为搜索字段建索引

索引并不一定就是给主键或是唯一的字段。如果在你的表中,有某个字段你总要会经常用来做搜索,那么,请为其建立索引吧。

从上图你可以看到那个搜索字串 “last_name LIKE ‘a%’”,一个是建了索引,一个是没有索引,性能差了4倍左右。

另外,你应该也需要知道什么样的搜索是不能使用正常的索引的。例如,当你需要在一篇大的文章中搜索一个词时,如: “WHERE post_content LIKE ‘%apple%’”,索引可能是没有意义的。你可能需要使用MySQL全文索引 或是自己做一个索引(比如说:搜索关键词或是Tag什么的)

5. 在Join表的时候使用相当类型的例,并将其索引

如果你的应用程序有很多 JOIN 查询,你应该确认两个表中Join的字段是被建过索引的。这样,MySQL内部会启动为你优化Join的SQL语句的机制。

而且,这些被用来Join的字段,应该是相同的类型的。例如:如果你要把 DECIMAL 字段和一个 INT 字段Join在一起,MySQL就无法使用它们的索引。对于那些STRING类型,还需要有相同的字符集才行。(两个表的字符集有可能不一样)

// 在state中查找company
$r = mysql_query("SELECT company_name FROM users
    LEFT JOIN companies ON (users.state = companies.state)
    WHERE users.id = $user_id");

// 两个 state 字段应该是被建过索引的,而且应该是相当的类型,相同的字符集。

 

6. 千万不要 ORDER BY RAND()

想打乱返回的数据行?随机挑一个数据?真不知道谁发明了这种用法,但很多新手很喜欢这样用。但你确不了解这样做有多么可怕的性能问题。

如果你真的想把返回的数据行打乱了,你有N种方法可以达到这个目的。这样使用只让你的数据库的性能呈指数级的下降。这里的问题是:MySQL会不得不去执行RAND()函数(很耗CPU时间),而且这是为了每一行记录去记行,然后再对其排序。就算是你用了Limit 1也无济于事(因为要排序)

下面的示例是随机挑一条记录

// 千万不要这样做:
$r = mysql_query("SELECT username FROM user ORDER BY RAND() LIMIT 1");

// 这要会更好:
$r = mysql_query("SELECT count(*) FROM user");
$d = mysql_fetch_row($r);
$rand = mt_rand(0,$d[0] - 1);

$r = mysql_query("SELECT username FROM user LIMIT $rand, 1");

 

7. 避免 SELECT *

从数据库里读出越多的数据,那么查询就会变得越慢。并且,如果你的数据库服务器和WEB服务器是两台独立的服务器的话,这还会增加网络传输的负载。

所以,你应该养成一个需要什么就取什么的好的习惯。

// 不推荐
$r = mysql_query("SELECT * FROM user WHERE user_id = 1");
$d = mysql_fetch_assoc($r);
echo "Welcome {$d['username']}";

// 推荐
$r = mysql_query("SELECT username FROM user WHERE user_id = 1");
$d = mysql_fetch_assoc($r);
echo "Welcome {$d['username']}";

 

8. 永远为每张表设置一个ID

我们应该为数据库里的每张表都设置一个ID做为其主键,而且最好的是一个INT型的(推荐使用UNSIGNED),并设置上自动增加的AUTO_INCREMENT标志。

就算是你 users 表有一个主键叫 “email”的字段,你也别让它成为主键。使用 VARCHAR 类型来当主键会使用得性能下降。另外,在你的程序中,你应该使用表的ID来构造你的数据结构。

而且,在MySQL数据引擎下,还有一些操作需要使用主键,在这些情况下,主键的性能和设置变得非常重要,比如,集群,分区……

在这里,只有一个情况是例外,那就是“关联表”的“外键”,也就是说,这个表的主键,通过若干个别的表的主键构成。我们把这个情况叫做“外键”。比如:有一个“学生表”有学生的ID,有一个“课程表”有课程ID,那么,“成绩表”就是“关联表”了,其关联了学生表和课程表,在成绩表中,学生ID和课程ID叫“外键”其共同组成主键。

9. 使用 ENUM 而不是 VARCHAR

ENUM 类型是非常快和紧凑的。在实际上,其保存的是 TINYINT,但其外表上显示为字符串。这样一来,用这个字段来做一些选项列表变得相当的完美。

如果你有一个字段,比如“性别”,“国家”,“民族”,“状态”或“部门”,你知道这些字段的取值是有限而且固定的,那么,你应该使用 ENUM 而不是 VARCHAR。

MySQL也有一个“建议”(见第十条)告诉你怎么去重新组织你的表结构。当你有一个 VARCHAR 字段时,这个建议会告诉你把其改成 ENUM 类型。使用 PROCEDURE ANALYSE() 你可以得到相关的建议。

10. 从 PROCEDURE ANALYSE() 取得建议

PROCEDURE ANALYSE() 会让 MySQL 帮你去分析你的字段和其实际的数据,并会给你一些有用的建议。只有表中有实际的数据,这些建议才会变得有用,因为要做一些大的决定是需要有数据作为基础的。

例如,如果你创建了一个 INT 字段作为你的主键,然而并没有太多的数据,那么,PROCEDURE ANALYSE()会建议你把这个字段的类型改成 MEDIUMINT 。或是你使用了一个 VARCHAR 字段,因为数据不多,你可能会得到一个让你把它改成 ENUM 的建议。这些建议,都是可能因为数据不够多,所以决策做得就不够准。

在phpmyadmin里,你可以在查看表时,点击 “Propose table structure” 来查看这些建议

一定要注意,这些只是建议,只有当你的表里的数据越来越多时,这些建议才会变得准确。一定要记住,你才是最终做决定的人。

11. 尽可能的使用 NOT NULL

除非你有一个很特别的原因去使用 NULL 值,你应该总是让你的字段保持 NOT NULL。这看起来好像有点争议,请往下看。

首先,问问你自己“Empty”和“NULL”有多大的区别(如果是INT,那就是0和NULL)?如果你觉得它们之间没有什么区别,那么你就不要使用NULL。(你知道吗?在 Oracle 里,NULL 和 Empty 的字符串是一样的!)

不要以为 NULL 不需要空间,其需要额外的空间,并且,在你进行比较的时候,你的程序会更复杂。 当然,这里并不是说你就不能使用NULL了,现实情况是很复杂的,依然会有些情况下,你需要使用NULL值。

下面摘自MySQL自己的文档:

“NULL columns require additional space in the row to record whether their values are NULL. For MyISAM tables, each NULL column takes one bit extra, rounded up to the nearest byte.”

12. Prepared Statements

Prepared Statements很像存储过程,是一种运行在后台的SQL语句集合,我们可以从使用 prepared statements 获得很多好处,无论是性能问题还是安全问题。

Prepared Statements 可以检查一些你绑定好的变量,这样可以保护你的程序不会受到“SQL注入式”攻击。当然,你也可以手动地检查你的这些变量,然而,手动的检查容易出问题,而且很经常会被程序员忘了。当我们使用一些framework或是ORM的时候,这样的问题会好一些。

在性能方面,当一个相同的查询被使用多次的时候,这会为你带来可观的性能优势。你可以给这些Prepared Statements定义一些参数,而MySQL只会解析一次。

虽然最新版本的MySQL在传输Prepared Statements是使用二进制形势,所以这会使得网络传输非常有效率。

当然,也有一些情况下,我们需要避免使用Prepared Statements,因为其不支持查询缓存。但据说版本5.1后支持了。

在PHP中要使用prepared statements,你可以查看其使用手册:mysqli 扩展 或是使用数据库抽象层,如: PDO.

// 创建 prepared statement
if ($stmt = $mysqli->prepare("SELECT username FROM user WHERE state=?")) {

    // 绑定参数
    $stmt->bind_param("s", $state);

    // 执行
    $stmt->execute();

    // 绑定结果
    $stmt->bind_result($username);

    // 移动游标
    $stmt->fetch();

    printf("%s is from %s\n", $username, $state);

    $stmt->close();
}

 

13. 无缓冲的查询

正常的情况下,当你在当你在你的脚本中执行一个SQL语句的时候,你的程序会停在那里直到没这个SQL语句返回,然后你的程序再往下继续执行。你可以使用无缓冲查询来改变这个行为。

关于这个事情,在PHP的文档中有一个非常不错的说明: mysql_unbuffered_query() 函数:

“mysql_unbuffered_query() sends the SQL query query to MySQL without automatically fetching and buffering the result rows as mysql_query() does. This saves a considerable amount of memory with SQL queries that produce large result sets, and you can start working on the result set immediately after the first row has been retrieved as you don’t have to wait until the complete SQL query has been performed.”

上面那句话翻译过来是说,mysql_unbuffered_query() 发送一个SQL语句到MySQL而并不像mysql_query()一样去自动fethch和缓存结果。这会相当节约很多可观的内存,尤其是那些会产生大量结果的查询语句,并且,你不需要等到所有的结果都返回,只需要第一行数据返回的时候,你就可以开始马上开始工作于查询结果了。

然而,这会有一些限制。因为你要么把所有行都读走,或是你要在进行下一次的查询前调用mysql_free_result() 清除结果。而且, mysql_num_rows() 或 mysql_data_seek() 将无法使用。所以,是否使用无缓冲的查询你需要仔细考虑。

14. 把IP地址存成 UNSIGNED INT

很多程序员都会创建一个 VARCHAR(15) 字段来存放字符串形式的IP而不是整形的IP。如果你用整形来存放,只需要4个字节,并且你可以有定长的字段。而且,这会为你带来查询上的优势,尤其是当你需要使用这样的WHERE条件:IP between ip1 and ip2。

我们必需要使用UNSIGNED INT,因为 IP地址会使用整个32位的无符号整形。

而你的查询,你可以使用 INET_ATON() 来把一个字符串IP转成一个整形,并使用 INET_NTOA() 把一个整形转成一个字符串IP。在PHP中,也有这样的函数 ip2long() 和 long2ip()

$r = "UPDATE users SET ip = INET_ATON('{$_SERVER['REMOTE_ADDR']}') WHERE user_id = $user_id";

15. 固定长度的表会更快

如果表中的所有字段都是“固定长度”的,整个表会被认为是 “static” 或 “fixed-length”。 例如,表中没有如下类型的字段: VARCHAR,TEXT,BLOB。只要你包括了其中一个这些字段,那么这个表就不是“固定长度静态表”了,这样,MySQL 引擎会用另一种方法来处理。

固定长度的表会提高性能,因为MySQL搜寻得会更快一些,因为这些固定的长度是很容易计算下一个数据的偏移量的,所以读取的自然也会很快。而如果字段不是定长的,那么,每一次要找下一条的话,需要程序找到主键。

并且,固定长度的表也更容易被缓存和重建。不过,唯一的副作用是,固定长度的字段会浪费一些空间,因为定长的字段无论你用不用,他都是要分配那么多的空间。

使用“垂直分割”技术(见下一条),你可以分割你的表成为两个一个是定长的,一个则是不定长的。

16. 垂直分割

“垂直分割”是一种把数据库中的表按列变成几张表的方法,这样可以降低表的复杂度和字段的数目,从而达到优化的目的。(以前,在银行做过项目,见过一张表有100多个字段,很恐怖)

示例一:在Users表中有一个字段是家庭地址,这个字段是可选字段,相比起,而且你在数据库操作的时候除了个人信息外,你并不需要经常读取或是改写这个字段。那么,为什么不把他放到另外一张表中呢? 这样会让你的表有更好的性能,大家想想是不是,大量的时候,我对于用户表来说,只有用户ID,用户名,口令,用户角色等会被经常使用。小一点的表总是会有好的性能。

示例二: 你有一个叫 “last_login” 的字段,它会在每次用户登录时被更新。但是,每次更新时会导致该表的查询缓存被清空。所以,你可以把这个字段放到另一个表中,这样就不会影响你对用户ID,用户名,用户角色的不停地读取了,因为查询缓存会帮你增加很多性能。

另外,你需要注意的是,这些被分出去的字段所形成的表,你不会经常性地去Join他们,不然的话,这样的性能会比不分割时还要差,而且,会是极数级的下降。

17. 拆分大的 DELETE 或 INSERT 语句

如果你需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询,你需要非常小心,要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的,表一锁住了,别的操作都进不来了。

Apache 会有很多的子进程或线程。所以,其工作起来相当有效率,而我们的服务器也不希望有太多的子进程,线程和数据库链接,这是极大的占服务器资源的事情,尤其是内存。

如果你把你的表锁上一段时间,比如30秒钟,那么对于一个有很高访问量的站点来说,这30秒所积累的访问进程/线程,数据库链接,打开的文件数,可能不仅仅会让你泊WEB服务Crash,还可能会让你的整台服务器马上掛了。

所以,如果你有一个大的处理,你定你一定把其拆分,使用 LIMIT 条件是一个好的方法。下面是一个示例:

while (1) {
    //每次只做1000条
    mysql_query("DELETE FROM logs WHERE log_date <= '2009-11-01' LIMIT 1000");
    if (mysql_affected_rows() == 0) {
        // 没得可删了,退出!
        break;
    }
    // 每次都要休息一会儿
    usleep(50000);
}

18. 越小的列会越快

对于大多数的数据库引擎来说,硬盘操作可能是最重大的瓶颈。所以,把你的数据变得紧凑会对这种情况非常有帮助,因为这减少了对硬盘的访问。

参看 MySQL 的文档 Storage Requirements 查看所有的数据类型。

如果一个表只会有几列罢了(比如说字典表,配置表),那么,我们就没有理由使用 INT 来做主键,使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更经济一些。如果你不需要记录时间,使用 DATE 要比 DATETIME 好得多。

当然,你也需要留够足够的扩展空间,不然,你日后来干这个事,你会死的很难看,参看Slashdot的例子(2009年11月06日),一个简单的ALTER TABLE语句花了3个多小时,因为里面有一千六百万条数据。

19. 选择正确的存储引擎

在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB,每个引擎都有利有弊。酷壳以前文章《MySQL: InnoDB 还是 MyISAM?》讨论和这个事情。

MyISAM 适合于一些需要大量查询的应用,但其对于有大量写操作并不是很好。甚至你只是需要update一个字段,整个表都会被锁起来,而别的进程,就算是读进程都无法操作直到读操作完成。另外,MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。

InnoDB 的趋势会是一个非常复杂的存储引擎,对于一些小的应用,它会比 MyISAM 还慢。他是它支持“行锁” ,于是在写操作比较多的时候,会更优秀。并且,他还支持更多的高级应用,比如:事务。

下面是MySQL的手册

20. 使用一个对象关系映射器(Object Relational Mapper)

使用 ORM (Object Relational Mapper),你能够获得可靠的性能增涨。一个ORM可以做的所有事情,也能被手动的编写出来。但是,这需要一个高级专家。

ORM 的最重要的是“Lazy Loading”,也就是说,只有在需要的去取值的时候才会去真正的去做。但你也需要小心这种机制的副作用,因为这很有可能会因为要去创建很多很多小的查询反而会降低性能。

ORM 还可以把你的SQL语句打包成一个事务,这会比单独执行他们快得多得多。

目前,个人最喜欢的PHP的ORM是:Doctrine

21. 小心“永久链接”

“永久链接”的目的是用来减少重新创建MySQL链接的次数。当一个链接被创建了,它会永远处在连接的状态,就算是数据库操作已经结束了。而且,自从我们的Apache开始重用它的子进程后——也就是说,下一次的HTTP请求会重用Apache的子进程,并重用相同的 MySQL 链接。

在理论上来说,这听起来非常的不错。但是从个人经验(也是大多数人的)上来说,这个功能制造出来的麻烦事更多。因为,你只有有限的链接数,内存问题,文件句柄数,等等。

而且,Apache 运行在极端并行的环境中,会创建很多很多的了进程。这就是为什么这种“永久链接”的机制工作地不好的原因。在你决定要使用“永久链接”之前,你需要好好地考虑一下你的整个系统的架构。

文章:来源

(全文完)

mysql 性能的检查和优化方法

导致性能下降的原因可能有:

1、索引没有建好;
2、sql写法过于复杂;
3、配置错误;
4、机器实在负荷不了;

下面分别详述:

1、索引没有建好 
如果看到mysql消耗的cpu很大,可以用mysql的client工具来检查。
在linux下执行

/usr/local/mysql/bin/mysql -hlocalhost -uroot -p

输入密码,如果没有密码,则不用-p参数就可以进到客户端界面中。

看看当前的运行情况

show full processlist

可以多运行几次

这个命令可以看到当前正在执行的sql语句,它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息
在我的cache后端,这里面大部分时间是看不到显示任何sql语句的,我认为这样才算比较正常。如果看到有很多sql语句,那么这台mysql就一定会有性能问题
如果出现了性能问题,则可以进行分析:
1、是不是有sql语句卡住了?
这是出现比较多的情况,如果数据库是采用myisam,那么有可能有一个写入的线程会把数据表给锁定了,如果这条语句不结束,则其它语句也无法运行。
查看processlist里的time这一项,看看有没有执行时间很长的语句,要留意这些语句。
2、大量相同的sql语句正在执行
如果出现这种情况,则有可能是该sql语句执行的效率低下,同样要留意这些语句。
然后把你所怀疑的语句统统集合一下,用desc(explain)来检查这些语句。
首先看看一个正常的desc输出:

mysql> desc select * from imgs where imgid=1651768337;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE | imgs | const | PRIMARY | PRIMARY | 8 | const | 1 | |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

注意key、rows和Extra这三项,这条语句返回的结果说明了该sql会使用PRIMARY主键索引来查询,结果集数量为1条,Extra没有显示,证明没有用到排序或其他操作。由此结果可以推断,mysql会从索引中查询imgid=1651768337这条记录,然后再到真实表中取出所有字段,是很简单的操作。

key是指明当前sql会使用的索引,mysql执行一条简单语句时只能使用到一条索引,注意这个限制;rows是返回的结果集大小,结果集就是使用该索引进行一次搜索的所有匹配结果;Extra一般会显示查询和排序的方式,。
如果没有使用到key,或者rows很大而用到了filesort排序,一般都会影响到效率,例如:

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| 1 | SIMPLE | imgs | ALL | NULL | NULL | NULL | NULL | 12506 | Using where; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)

这条sql结果集会有12506条,用到了filesort,所以执行起来会非常消耗效率的。这时mysql执行时会把整个表扫描一遍,一条一条去找到匹配userid=”7mini”的记录,然后还要对这些记录的clicks进行一次排序,效率可想而知。真实执行时如果发现还比较快的话,那是因为服务器内存还足够将12506条比较短小的记录全部读入内存,所以还比较快,但是并发多起来或者表大起来的话,效率问题就严重了。

这时我把userid加入索引:

create index userid on imgs (userid);

然后再检查:

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE | imgs | ref | userid | userid | 51 | const | 8 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

嗯,这时可以看到mysql使用了userid这个索引搜索了,用userid索引一次搜索后,结果集有8条。然后虽然使用了filesort一条一条排序,但是因为结果集只有区区8条,效率问题得以缓解。

但是,如果我用别的userid查询,结果又会有所不同:

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE | imgs | ref | userid | userid | 51 | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这个结果和userid=”7mini”的结果基本相同,但是mysql用userid索引一次搜索后结果集的大小达到2944条,这2944条记录都会加入内存进行filesort,效率比起7mini那次来说就差很多了。这时可以有两种办法可以解决,第一种办法是再加一个索引和判断条件,因为我只需要根据点击量取最大的10条数据,所以有很多数据我根本不需要加进来排序,比如点击量小于10的,这些数据可能占了很大部分。

我对clicks加一个索引,然后加入一个where条件再查询:

create index clicks on imgs(clicks);
mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE | imgs | ref | userid,clicks | userid | 51 | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这时可以看到possible_keys变成了userid,clicks,possible_keys是可以匹配的所有索引,mysql会从possible_keys中自己判断并取用其中一个索引来执行语句,值得注意的是,mysql取用的这个索引未必是最优化的。这次查询mysql还是使用userid这个索引来查询的,并没有按照我的意愿,所以结果还是没有什么变化。改一下sql加上use index强制mysql使用clicks索引:

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>10 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE | imgs | range | clicks | clicks | 4 | NULL | 5455 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

这时mysql用到了clicks索引进行查询,但是结果集比userid还要大!看来还要再进行限制:

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>1000 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE | imgs | range | clicks | clicks | 4 | NULL | 312 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

加到1000的时候结果集变成了312条,排序效率应该是可以接受。

不过,采用换索引这种优化方式需要取一个采样点,比如这个例子中的1000这个数字,这样,对userid的每个数值,都要去找一个采样点,这样对程序来说是很难办的。如果按1000取样的话,那么userid=’7mini’这个例子中,取到的结果将不会是8条,而是2条,给用户造成了困惑。
当然还有另一种办法,加入双索引:

create index userid_clicks on imgs (userid, clicks)
mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| 1 | SIMPLE | imgs | ref | userid,userid_clicks | userid_clicks | 51 | const | 2944 | Using where |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
1 row in set (0.00 sec)

这时可以看到,结果集还是2944条,但是Extra中的filesort不见了。这时mysql使用userid_clicks这个索引去查询,这不但能快速查询到userid=”admin”的所有记录,并且结果是根据clicks排好序的!所以不用再把这个结果集读入内存一条一条排序了,效率上会高很多。

但是用多字段索引这种方式有个问题,如果查询的sql种类很多的话,就得好好规划一下了,否则索引会建得非常多,不但会影响到数据insert和update的效率,而且数据表也容易损坏。
以上是对索引优化的办法,因为原因可能会比较复杂,所以写得比较的长,一般好好优化了索引之后,mysql的效率会提升n个档次,从而也不需要考虑增加机器来解决问题了。
但是,mysql甚至所有数据库,可能都不好解决limit的问题。在mysql中,limit 0,10只要索引合适,是没有问题的,但是limit 100000,10就会很慢了,因为mysql会扫描排好序的结果,然后找到100000这个点,取出10条返回。要找到100000这个点,就要扫描100000条记录,这个循环是比较耗时的。不知道会不会有什么好的算法可以优化这个扫描引擎,我冥思苦想也想不出有什么好办法。对于limit,目前直至比较久远的将来,我想只能通过业务、程序和数据表的规划来优化,我想到的这些优化办法也都还没有一个是万全之策,往后再讨论。
2、sql写法过于复杂
sql写法假如用到一些特殊的功能,比如groupby、或者多表联合查询的话,mysql用到什么方式来查询也可以用desc来分析,我这边用复杂sql的情况还不算多,所以不常分析,暂时就没有好的建议。
3、配置错误
配置里主要参数是key_buffer、sort_buffer_size/myisam_sort_buffer_size,这两个参数意思是:
key_buffer=128M:全部表的索引都会尽可能放在这块内存区域内,索引比较大的话就开稍大点都可以,我一般设为128M,有个好的建议是把很少用到并且比较大的表想办法移到别的地方去,这样可以显著减少mysql的内存占用。
sort_buffer_size=1M:单个线程使用的用于排序的内存,查询结果集都会放进这内存里,如果比较小,mysql会多放几次,所以稍微开大一点就可以了,重要是优化好索引和查询语句,让他们不要生成太大的结果集。
另外一些配置:
thread_concurrency=8:这个配置标配=cpu数量x2
interactive_timeout=30
wait_timeout=30:这两个配置使用10-30秒就可以了,这样会尽快地释放内存资源,注意:一直在使用的连接是不会断掉的,这个配置只是断掉了长时间不动的连接。
query_cache:这个功能不要使用,现在很多人看到cache这几个字母就像看到了宝贝,这是不唯物主义的。mysql的query_cache在每次表数据有变化的时候都会重新清理连至该表的所有缓存,如果更新比较频繁,query_cache不但帮不上忙,而且还会对效率影响很大。这个参数只适合只读型的数据库,如果非要用,也只能用query_cache_type=2自行用SQL_CACHE指定一些sql进行缓存。
max_connections:默认为100,一般情况下是足够用的,但是一般要开大一点,开到400-600就可以了,能超过600的话一般就有效率问题,得另找对策,光靠增加这个数字不是办法。
其它配置可以按默认就可以了,个人觉得问题还不是那么的大,提醒一下:

1、配置虽然很重要,但是在绝大部分情况下都不是效率问题的罪魁祸首。

2、mysql是一个数据库,对于数据库最重要考究的不应是效率,而是稳定性和数据准确性。

4、机器实在负荷不了
如果做了以上调整,服务器还是不能承受,那就只能通过架构级调整来优化了。

1、mysql同步。
通过mysql同步功能将数据同步到数台从数据库,由主数据库写入,从数据库提供读取。
我个人不是那么乐意使用mysql同步,因为这个办法会增加程序的复杂性,并常常会引起数据方面的错误。在高负荷的服务中,死机了还可以快速重启,但数据错误的话要恢复就比较麻烦。
2、加入缓存
加入缓存之后,就可以解决并发的问题,效果很明显。如果是实时系统,可以考虑用刷新缓存方式使缓存保持最新。
在前端加入squid的架构比较提倡使用,在命中率比较高的应用中,基本上可以解决问题。
如果是在程序逻辑层里面进行缓存,会增加很多复杂性,问题会比较多而且难解决,不建议在这一层面进行调整。
3、程序架构调整,支持同时连接多个数据库
如果web加入缓存后问题还是比较严重,只能通过程序架构调整,把应用拆散,用多台的机器同时提供服务。
如果拆散的话,对业务是有少许影响,如果业务当中有部分功能必须使用所有的数据,可以用一个完整库+n个分散库这样的架构,每次修改都在完整库和分散库各操作一次,或定期整理完整库。
当然,还有一种最笨的,把数据库整个完完整整的做拷贝,然后程序每次都把完整的sql在这些库执行一遍,访问时轮询访问,我认为这样要比mysql同步的方式安全。
4、使用 mysql proxy 代理
mysql proxy 可以通过代理把数据库中的各个表分散到数台服务器,但是它的问题是没有能解决热门表的问题,如果热门内容散在多个表中,用这个办法是比较轻松就能解决问题。
我没有用过这个软件也没有认真查过,不过我对它的功能有一点点怀疑,就是它怎么实现多个表之间的联合查询?如果能实现,那么效率如何呢?
5、使用memcachedb
数据库换用支持mysql的memcachedb,是可以一试的想法,从memcachedb的实现方式和层面来看对数据没有什么影响,不会对用户有什么困扰。
为我现在因为数据库方面问题不多,没有试验过这个玩意。不过,只要它支持mysql的大部分主要的语法,而且本身稳定,可用性是无需置疑的。

数据库优化

<<<先记录,后面再整理>>>

 

问题发起:

起初数据库没做过多设计,所以实时数据都放在实时表里了,天长日久,这张表就膨胀了。

最关心的问题是mysql到底对单个表的管理能力有多强,单个表能达到多大?数据条数达到多少会影响访问性能?

 windows server 2008 64位OS、mysql、5.1、局域网千兆网卡、40个下位机,上报频率20秒一次,Raid5、8G内存、3.2G8CPU

问题比这简单多了:并发访问不大,就几个大佬要开个会,查查历史数据,讨论一下生产线的瓶颈在哪儿,提供一点数据说明,所以没啥并发量,对历史数据的访问,就是做几个报告;问题在于时间长了,如果是单表,表大了,想分小点,仅此而已。

 

讨论过程中,发现很多同学都往I/O、并发量、磁盘阵列等访问优化上讨论了,才发现大部分同学都是处理Web高并发访问的高手,把问题都推向了解决并发访问的方向去了:方向错了

 

mysql到底对单个表的管理能力有多强,单个表能达到多大?数据条数达到多少会影响访问性能?下面搜到了一些信息(注:现在的mysql已经是5.1了):

MySQL 3.22限制的表大小为4GB。由于在MySQL 3.23中使用了MyISAM存储引擎,最大表尺寸增加到了65536TB(2567 – 1字节)。由于允许的表尺寸更大,MySQL数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的,而不是由MySQL内部限制决定的。

InnoDB存储引擎将InnoDB表保存在一个表空间内,该表空间可由数个文件创建。这样,表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区,从而使得很大的表成为可能。表空间的最大容量为64TB。

配置新cygwin eclipse CDT mysql碰到的三个问题及其解决办法

1、Cannot run program “make”错误:

 在Windows环境变量中加入 CYGWIN 变量, 并且将 %CYGWIN%\bin 加入到Path中(我顺便在系统环境变量和用户环境变量中都加了), 不用重启Windows, 但必须记得重启eclipse!
2、GDB
上一次在台式机上的配置始终不能启动gdb,这次顺便解决:
配置GDB C库的source path:
此处参照了网上的一个解释。
3、cygmpfr-4.dll找不到:
 error while loading shared libraries: cygmpfr-4.dll:cannot open shared object file: No such file or directory
Try installing libmpfr4.(打开cygwin安装程序,选中libmpfr4,安装,解决问题)

解决mysql连接问题:Can’t connect to MySQL server on ‘ ’ (113)

今天应用服务器出现“Can’t connect to MySQL server on ‘   ’ (113)”的错误,连不上mysql数据库服务器了。

应用服务器运行在Windows7中的一个VMware Ubuntu虚拟机里,网上有资料说是防火墙的问题,关闭Win7的防火墙,还是一样,报“Can’t connect to MySQL server on (113)”错误。

ping主机也ping不通;打开firefox浏览器,无法上网浏览网页,应该就是虚拟机的问题了。

从虚拟机的菜单“VM->Settings…”,在Device列表中选择“Network Adapter”,以前是NAT模式,改成Bridged模式,再次运行程序,OK了。

上个图:

 

 

说明一下,这个问题跟win7的防火墙是没啥关系的,放心开着吧。

 

Ubuntu linux下安装Eclipse PDT步骤

作者 FarLee 2010年3月21日 16:48:08

在Ubuntu Linux下进行PHP开发,首先可以安装搭建 LAMP 环境和 phpmyadmin 这个Mysql 数据库管理工具,之后选择一个FTP传工具如:Filezilla,最后我们还要选择PHP开发工具,Ubuntu自带的Gedit纯文本编辑做一般的代码文本的修改足够,但要实现一些项目和调试等功能就不行了,所以我们还是最好还是选择一款IDE开发环境,这里我们选择了Eclipse (PDT)。

Eclipse 最初由IBM公司开发的IDE开发环境贡献给开源社区,优点很多了,什么跨平台、免费开放源代码、自由IDE(集成开发环境)等等。最初只是用于java语言开发,再添加Eclipse插件就可以应用于其他语言如 C/C++(CDT)、Perl、Ruby,Python、telnet 和数据库的开发。PHP也一样,在Eclipse 中安装 PDT(PDT: PHP Development Tools) 插件就可以当作 PHP开发工具了。PDT 同时支持XDebug 和 Zend Debugger 这两种调试工具。

Eclipse PDT 下载

如果你以前没有安装过Eclipse,那么不用先安装Eclipse,再安装PDT插件了。Eclipse官方网站直接提供了All in one 打包下载的版本,包括了PDT 2.1-SR2, Eclipse 3.5-SR2, Mylyn和其他PHP开发必须的插件。进入ALL IN ONE PDT 下载页面,选择适合的Linux版本,如 eclipse-php-galileo-SR2-linux-gtk.tar.gz 下载过来即可。

Eclipse PDT 安装步骤

1. 安装Eclipse 开发环境 JDK / JRE

Eclipse 是运行于Java虚拟机中的,所以必须先安装Java环境才能进行开发测试。在这里可以选择下载JDK 或者JRE。JRE(Java Runtime Environment)是运行环境,JDK(Java Development Kit)是开发环境,JDK开发环境中包括JRE运行环境。所以如果只是使用Eclipse开发PHP程序,JDK不是必须的,JRE即可;如果同时也要进行Java语言的开发,那么JDK才是必须的。

在Ubuntu 中安装了JDK就不用再安装JRE了,如安装了JRE,再安装JDK会重新再装一个JRE。打开Ubuntu终端,使用命令:
sudo apt-get install sun-java6-jre 或 sudo apt-get install sun-java6-jdk

或使用Ubuntu新立得软件包管理器,搜索jdk找到 sun-java6-jdk ,选中刷新–标记以便升级–应用。安装JDK完毕即可。

Update:Ubuntu 10.04 lucid将sun-java6-jdk/jdk 移除了,ubuntu官方推荐使用openjdk-6,但是安装defaut-jdk/jre时出现很多依赖性问题,无法安装。既然它指出仍然可以使用sun-java6-jdk/jdk,在源里面加入system->Administration->Software Sources->other sources->Add ,添加deb http://archive.canonical.com/ lucid partner

2. 安装 Eclipse PDT

将下载过来的Eclipse PDT压缩包 (All-In-One Linux x86/GTK 2 32-bit)解压到适当的适当的目录中,只要jdk/jre环境搭建好,Eclipse解压文件夹放在哪里没关系。执行解压终端命令:

sudo tar -zxvf ‘/home/farlee/下载/eclipse-php-galileo-SR2-linux-gtk.tar.gz’

解压到了/home/farlee 目录下,Eclipse解压缩后,不用再./configure #make install之类的安装即可使用。

3. 添加Eclipse应用程序图标

在Ubuntu 桌面左上角应用程序的编程菜单中添加Eclipse 快捷方式图标:
sudo gedit /usr/share/applications/eclipse.desktop

在Gedit打开的文件中加入下面的代码:

[Desktop Entry]
Encoding=UTF-8
Name=Eclipse
Comment=Eclipse IDE
Exec=/home/farlee/eclipse/eclipse  //改成自己安装Eclipse可执行文件的目录路径
Icon=/home/farlee/eclipse/icon.xpm  //改成自己的Eclipse 图标路径
Terminal=false
StartupNotify=true
Type=Application
Categories=Application;Development;  //指应用程序;编程

保存退出即可。在该图标中右键可以将Eclipse添加到桌面启动器。

4. Eclipse 设置工作区

设置工作区Wrkspace为自己的 www 目录即可。

最后再安装一个XDebug PHP调试工具就更好了。

原创文章,转载请注明出处:远方博客
本文固定链接:http://farlee.info/archives/ubuntu-linux-eclipse-pdt-jdk-jre-php.html

感谢作者分享!

关于两个问题:日志的自动备份脚本、mysql重置密码

=================================================
本文为HeYuanHui原作

转载必须确保本文完整并完整保留原作者信息及本文原始链接!

NN:      khler
E-mail: khler@163.com
QQ:     23381103
MSN:   pragmac@hotmail.com
=================================================

 

最近在Linux下实现一个服务,名为tws,它利用syslog输出日志,利用mysql作为后台数据库。此间碰到了两个问题,浪费了相当相当相当(印象实在太深刻了:)…)长的时间才得以解决,现记录于此,希望能够帮到与我有同样问题的朋友,节约宝贵时间。

一、日志输出及自动备份脚本:

通过cron服务,我们可以实现定时执行脚本,我这里当然是每天定时执行twslogbaker.sh脚本,备份我的tws产生的日志信息,我把它放在了tws服务的可执行文件同目录下,这当然是个普通的目录,结果让人郁闷的是,手动执行此脚本没问题,cron定时执行时,syslog不能向新产生的tws.log文件中写入信息…

具体做法是:

1、输出日志:

在我的tws服务里面,启动时调用: openlog(“tws”, LOG_NDELAY,LOG_USER);退出前调用: closelog();中间输出日志: syslog(LOG_INFO|LOG_LOCAL6, “%s”, buff);

然后在/etc/syslog.conf(如果是ubuntu,在/etc/rsyslog/下添加.conf文件,具体参见ubuntu的rsyslog文档)

tws.*               /usr/local/twslog/tws.log

2、定时备份:

在/etc/crontab中加入:59 23 * * * root /usr/sbin/twslogbaker.sh,这样每天晚上的23点59分执行/usr/sbin/下的脚本twslogbaker.sh。

twslogbaker.sh脚本是用来备份tws.log日志的,脚本内容:

 

#!/bin/sh

# 当前日期
currdate=$( date +%Y-%m-%d )

# 日志路径
path=/usr/local/twslog

# 原始文件
orgfile=tws.log

# 新文件
dailyfile=$currdate.log

echo —> Log path: ‘$path’
echo 
—> Starting bak ‘$orgfile’ to ‘$dailyfile’ …

# Is ‘tws.log’ file exist?
#
if [ ! -r $logfile ]
if [ r $path/$orgfile ]
then
  
# bake up log file
  echo —> rename ‘$orgfile’ to ‘$dailyfile’
  mv $path
/$orgfile $path/$dailyfile
else
  echo 
—> file ‘$orgfile’ not exist!
fi

# empty tws.log
#
echo “—> create ‘$orgfile’ file”
touch $path/$orgfile
#chown root $path/$orgfile
chmod 666 $path/$orgfile

 
echo —> Done!

 

 

 

以前没有将twslogbaker.sh脚本放在/usr/sbin/下,导致备份完后syslog不能往新的tws.log文件中写入内容,放到/usr/sbin/就可以了,是因为权限的问题吗?到现在还不是很清楚,知道的兄弟给解释一下 :)

 

二、mysql重置密码:

参照了这篇文章:

http://sundful.javaeye.com/blog/704337

 
引用
Mysql ERROR 1045 (28000): Access denied for user ‘root’@’localhost’问题的解决

这种问题需要强行重新修改密码方法如下:

/etc/init.d/mysql stop   (service mysqld stop )
/usr/bin/mysqld_safe –skip-grant-tables
另外开个SSH连接
[root@localhost ~]# mysql
mysql>use mysql
mysql>update user set password=password(“123456″) where user=”root”;
mysql>flush privileges;
mysql>exit

pkill -KILL -t pts/0 可将pts为0的**用户(之前运行mysqld_safe的用户窗口)强制踢出
正常启动 MySQL:/etc/init.d/mysql start   (service mysqld start)

注意:另外还遇到需要service mysql star才能启动service mysql stop才能停止。
还有直接使用mysql不能找到命令,错误为“bash: mysql: command not found”可以直接**mysql的安装目录中的bin文件夹跟绝对路径运行命令,还有的需要加./mysql 才能执行。

 

 

最后一步即pkill的时候一定要注意,你首先打开的不一定是pts/0,也可能是pst/1、pst/2…,所以,最保险的方法是:直接关闭那个命令窗口就行了。我之前pkill的时候可能没有正确执行,导致重置了密码后任然不能登录,一样的“Mysql ERROR 1045 (28000): Access denied for user ‘root’@’localhost’问题”,弄得我头大…

 

 

解决Mysql ERROR 1045 (28000): Access denied for user ‘root’@’localhost’问题

 
ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: NO)
 
Red Hat Enterprise Linux 5服务器上mysql启动报错:ERROR 1045 (28000): Access denied for user ‘root’@’localhost’ (using password: NO)
原因1-启动命令错误:
我开始的时候直接输入命令:mysql start
正确的启动命令是:
/etc/rc.d/init.d/mysql start

原因2-配置文件错误:
检查etc下面的my.cnf如下内容:

[client]
#password   = your_password
port     = 3306
socket     = /usr/mysql-data/mysql.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
port     = 3306
socket     = /usr/mysql-data/mysql.sock

原因3-启动文件错误:
需要修改MySQL启动脚本/etc/rc.d/init.d/mysql,
其中datadir=   ?     一行检查下!

原因4-前提是你在使用php连接时候报错!
在/etc/php.ini修改mysql.default_socket的值设置为:
mysql.default_socket=/var/lib/mysql/mysql.sock
回到终点设置个连接:ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
(在/etc/php.ini中mysql.default_socket这个文件中,关于mysql.default_socket的值的说明是这样的,
;Default socket name for local MySQL connects. If empty, uses the built-in MySQL defaults.
这个值一开始是空的,也就是说,如果我们不主动去修改的话,php将会使用内建在mysql中的默认值)

 
另一篇文章:
Mysql ERROR 1045 (28000): Access denied for user ‘root’@’localhost’问题的解决

这种问题需要强行重新修改密码方法如下:

/etc/init.d/mysql stop   (service mysqld stop )
/usr/bin/mysqld_safe –skip-grant-tables
另外开个SSH连接
[root@localhost ~]# mysql
mysql>use mysql
mysql>update user set password=password(“123456″) where user=”root”;
mysql>flush privileges;
mysql>exit

pkill -KILL -t pts/0 可将pts为0的**用户(之前运行mysqld_safe的用户窗口)强制踢出
正常启动 MySQL:/etc/init.d/mysql start   (service mysqld start)

注意:另外还遇到需要service mysql star才能启动service mysql stop才能停止。
还有直接使用mysql不能找到命令,错误为“bash: mysql: command not found”可以直接**mysql的安装目录中的bin文件夹跟绝对路径运行命令,还有的需要加./mysql 才能执行。

 
 
另一篇关于清除密码、重置用户的文章:
 

Quote:
First things first. Log in as root and stop the mysql daemon.

sudo /etc/init.d/mysql stop

Now lets start up the mysql daemon and skip the grant tables which store the passwords.

sudo mysqld_safe –skip-grant-tables&

(press Ctrl+C now to disown the process and start typing commands again)

You should see mysqld start up successfully. If not, well you have bigger issues. Now you should be able to connect to mysql without a password.

sudo mysql –user=root mysql

update user set Password=PASSWORD(‘new-password’);
flush privileges;
exit;

Now kill your running mysqld then restart it normally.

sudo killall mysqld_safe&
(press Ctrl+C now to disown the process and start typing commands again)
/etc/init.d/mysql start

You should be good to go. Try not to forget your password again.

 
 
另外关于denied的总结:

MySQL Authentication Denial

It seems to me that a lot of people have auth denial when trying to make connections to MySQL. They seem to ignore the text of the error message. ‘Access Denied’ means access denied, nothing else.

Remember three things have to match. The host as MySQL sees it, the username, and the password. When MySQL returns access denied it’s not broken. One or more of those three things does not match. I don’t really need to reiterate what’s in the manual. Chang the lock or change the key to make it fit.

其中连接到mysql的文档内容为: