问个mysql优化问题

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select from t1 where f1 = 20;

B：

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数：

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL：

SQL C：

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划：

不加HINT，

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT，

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看，很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要象普通由CLIENT提交的SQL那样进行处理和编译。8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了获取少量字段而写SELECT 对性能的损害也比较利害。9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。10、评估你开发系统的关键业务，在很多数据库系统对性能的要求是彼此矛盾的，比如OLTP应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度，而大量的索引对OLTP则是负担。11、不要在应用程序中写怪异的SQL 查询，比如 WHERE money!40000，这样的语句，这种SQL查询，数据库的SQL优化器是无法进行优化的。12、定期维护和管理你的数据库系统，压缩掉那些垃圾空间，很多数据库系统执行类似删除，事务等 *** 作的时候，并不回收无用的物理空间。所以，制定一份合理的数据库维护计划，不要等日志文件或者LOG文件越长越大的时候才去整理数据库。还有很多很多要注意的东西，。。。。。。

 MySQL数据库:

MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），使用最常用的数据库管理语言--结构化查询语言（SQL）进行数据库管理。

MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。

MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。

数据库简介:

MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），MySQL数据库系统使用最常用的数据库管理语言--结构化查询语言（SQL）进行数据库管理。

由于MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。

MySQL这个名字，起源不是很明确。一个比较有影响的说法是，基本指南和大量的库和工具带有前缀“my”已经有10年以上，而且不管怎样，MySQL AB创始人之一的Monty Widenius的女儿也叫My。这两个到底是哪一个给出了MySQL这个名字至今依然是个迷，包括开发者在内也不知道。

MySQL的海豚标志的名字叫“sakila”，它是由MySQL AB的创始人从用户在“海豚命名”的竞赛中建议的大量的名字表中选出的。获胜的名字是由来自非洲斯威士兰的开源软件开发者Ambrose Twebaze提供。根据Ambrose所说，Sakila来自一种叫SiSwati的斯威士兰方言，也是在Ambrose的家乡乌干达附近的坦桑尼亚的Arusha的一个小镇的名字。

MySQL，虽然功能未必很强大，但因为它的开源、广泛传播，导致很多人都了解到这个数据库。它的历史也富有传奇性。

MySQL数据库历史:

MySQL的历史最早可以追溯到1979年，那时Oracle也才小打小闹，微软的SQL Server影子都没有。有一个人叫Monty Widenius, 为一个叫TcX的小公司打工，并用BASIC设计了一个报表工具，可以在4M主频和16KB内存的计算机上运行。过了不久，又将此工具，使用C语言重写，移植到Unix平台，当时，它只是一个很底层的面向报表的存储引擎。这个工具叫做Unireg。

可是，这个小公司资源有限，Monty天赋极高，面对资源有限的不利条件，他反而更能发挥潜能，总是力图写出最高效的代码。并因此养成了习惯。与Monty同在一起的还有一些别的同事，很少有人能坚持把那些代码持续写到20年后，而Monty却做到了。

1990年，TcX的customer 中开始有人要求要为它的API提供SQL支持，当时，有人想到了直接使用商用数据库算了，但是Monty觉得商用数据库的速度难令人满意。于是，他直接借助于mSQL的代码，将它集成到自己的存储引擎中。但不巧的是，效果并不太好。于是, Monty雄心大起，决心自己重写一个SQL支持。

1996年，MySQL 10发布,只面向一小拨人，相当于内部发布。到了96年10月，MySQL 3111发布了，呵呵，没有2x版本。最开始，只提供了Solaris下的二进制版本。一个月后，Linux版本出现了。

紧接下来的两年里，MySQL依次移植到各个平台下。它发布时，采用的许可策略，有些与众不同：允许免费商用，但是不能将MySQL与自己的产品绑定在一起发布。如果想一起发布，就必须使用特殊许可，意味着要花银子。当然，商业支持也是需要花银子的。其它的，随用户怎么用都可以。这种特殊许可为MySQL带来了一些收入，从而为它的持续发展打下了良好的基础。（细想想，PostgreSQL曾经有几年限入低谷，可能与它的完全免费，不受任何限制有关系）。

MySQL322应该是一个标志性的版本，提供了基本的SQL支持。

MySQL关系型数据库于1998年1月发行第一个版本。它使用系统核心提供的多线程机制提供完全的多线程运行模式，提供了面向C、C++、Eiffel、Java、Perl、PHP、Python以及Tcl等编程语言的编程接口（APIs），支持多种字段类型并且提供了完整的 *** 作符支持查询中的SELECT和WHERE *** 作。

MySQL是开放源代码的，因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。

1999-2000年，有一家公司在瑞典成立了，叫MySQL AB (AB是瑞典语“股份公司”的意思)。 雇了几个人,与Sleepycat合作，开发出了 Berkeley DB引擎, 因为BDB支持事务处理，所以，MySQL从此开始支持事务处理了。

2000年4月，MySQL对旧的存储引擎进行了整理，命名为MyISAM。同时，2001年，Heikiki Tuuri向MySQL提出建议，希望能集成他们的存储引擎InnoDB，这个引擎同样支持事务处理，还支持行级锁。

如今，遗憾的是，BDB和InnoDB好像都被Oracle收购了，为了消灭竞争对手，哪怕是开源的，都是不择手段。

MySQL与InnoDB的正式结合版本是40。

到了MySQL50，2003年12月，开始有View,存储过程之类的东东，当然，其间, bug也挺多。

在2008年1月16号 MySQL被Sun公司收购。

最近，MySQL的创始人Monty Widenius已经向Sun提交了辞呈。head都要走了。

据说，被Sun收购的公司多薄命，不知道MySQL今后前途如何，希望一路走好。相信MySQL的生命力还是很长久的。

时至今日 mysql 和 php 的结合绝对是完美很多大型的网站也用到mysql数据库mysql的发展前景是非常光明的!

MySQL常用命令:

1:使用SHOW语句找出在服务器上当前存在什么数据库：

mysql> SHOW DATABASES;

2:2、创建一个数据库MYSQLDATA

mysql> CREATE DATABASE MYSQLDATA;

3:选择你所创建的数据库

mysql> USE MYSQLDATA; (按回车键出现Database changed 时说明 *** 作成功！)

4:查看现在的数据库中存在什么表

mysql> SHOW TABLES;

5:创建一个数据库表

mysql> CREATE TABLE MYTABLE (name VARCHAR(20), sex CHAR(1));

6:显示表的结构：

mysql> DESCRIBE MYTABLE;

7:往表中加入记录

mysql> insert into MYTABLE values (”hyq”,”M”);

8:用文本方式将数据装入数据库表中（例如D:/mysqltxt）

mysql> LOAD DATA LOCAL INFILE “D:/mysqltxt” INTO TABLE MYTABLE;

9:导入sql文件命令（例如D:/mysqlsql）

mysql>use database;

mysql>source d:/mysqlsql;

10:删除表

mysql>drop TABLE MYTABLE;

11:清空表

mysql>delete from MYTABLE;

12:更新表中数据

mysql>update MYTABLE set sex=”f” where name=’hyq’;

全局管理权限对应解释：

FILE: 在MySQL服务器上读写文件。

PROCESS: 显示或杀死属于其它用户的服务线程。

RELOAD: 重载访问控制表，刷新日志等。

SHUTDOWN: 关闭MySQL服务。

数据库/数据表/数据列权限：

ALTER: 修改已存在的数据表(例如增加/删除列)和索引。

CREATE: 建立新的数据库或数据表。

DELETE: 删除表的记录。

DROP: 删除数据表或数据库。

INDEX: 建立或删除索引。

INSERT: 增加表的记录。

SELECT: 显示/搜索表的记录。

UPDATE: 修改表中已存在的记录。

特别的权限：

ALL: 允许做任何事(和root一样)。

USAGE: 只允许登录–其它什么也不允许做。

MySQL数据库导入方法:

MySQL数据库的导入,有两种方法：

1) 先导出数据库SQL脚本，再导入；

2) 直接拷贝数据库目录和文件。

在不同 *** 作系统或MySQL版本情况下，直接拷贝文件的方法可能会有不兼容的情况发生。

所以一般推荐用SQL脚本形式导入。下面分别介绍两种方法。

2 方法一 SQL脚本形式

*** 作步骤如下：

21 导出SQL脚本

在原数据库服务器上，可以用phpMyAdmin工具，或者mysqldump命令行，导出SQL脚本。

211 用phpMyAdmin工具

导出选项中，选择导出“结构”和“数据”，不要添加“DROP DATABASE”和“DROP TABLE”选项。

选中“另存为文件”选项，如果数据比较多，可以选中“gzipped”选项。

将导出的SQL文件保存下来。

212 用mysqldump命令行

命令格式

mysqldump -u 用户名 -p 数据库名 > 数据库名sql

范例：

mysqldump -u root -p abc > abcsql

（导出数据库abc到abcsql文件）

提示输入密码时，输入该数据库用户名的密码。

22 创建空的数据库

通过主控界面/控制面板，创建一个数据库。假设数据库名为abc，数据库全权用户为abc_f。

23 将SQL脚本导入执行

同样是两种方法，一种用phpMyAdmin（mysql数据库管理）工具，或者mysql命令行。

231 用phpMyAdmin工具

从控制面板，选择创建的空数据库，点“管理”，进入管理工具页面。

在"SQL"菜单中，浏览选择刚才导出的SQL文件，点击“执行”以上载并执行。

注意：phpMyAdmin对上载的文件大小有限制，php本身对上载文件大小也有限制，如果原始sql文件

比较大，可以先用gzip对它进行压缩，对于sql文件这样的文本文件，可获得1:5或更高的压缩率。

gzip使用方法：

# gzip xxxxxsql

得到

xxxxxsqlgz文件。

提示输入密码时，输入该数据库用户名的密码。

3 直接拷贝

如果数据库比较大，可以考虑用直接拷贝的方法，但不同版本和 *** 作系统之间可能不兼容，要慎用。

31 准备原始文件

用tar打包为一个文件

32 创建空数据库

33 解压

在临时目录中解压，如：

cd /tmp

tar zxf mydbtargz

34 拷贝

将解压后的数据库文件拷贝到相关目录

cd mydb/

cp /var/lib/mysql/mydb/

对于FreeBSD:

cp /var/db/mysql/mydb/

35 权限设置

将拷贝过去的文件的属主改为mysql:mysql，权限改为660

chown mysql:mysql /var/lib/mysql/mydb/

chmod 660 /var/lib/mysql/mydb/

Mssql转换mysql的方法:

1导表结构

使用MySQL生成create脚本的方法。找到生成要导出的脚本，按MySQL的语法修改一下到MySQL数据库中创建该表的列结构什么的。

2导表数据

在MSSQL端使用bcp导出文本文件:

bcp “Select FROM dbnamedbotablename;” queryout tablenametxt -c -Slocalhost\db2005 -Usa

其中”"中是要导出的sql语句,-c指定使用\t进行字段分隔,使用\n进行记录分隔,-S指定数据库服务器及实例,-U指定用户名,-P指定密码

在MySQL端使用mysqlimport 导入文本文件到相应表中

mysqlimport -uroot -p databasename /home/test/tablenametxt

其中-u指定用户名,-p指定密码,databasename指定数据库名称,表名与文件名相同

MySQL备份与恢复:

MySQL备份恢复数据的一般步骤

备份一个数据库的例子：

1、备份前读锁定涉及的表

mysql>LOCK TABLES tbl1 READ,tbl1 READ,…

如果，你在mysqldump实用程序中使用--lock-tables选项则不必使用如上SQL语句。

2、导出数据库中表的结构和数据

shell>mysqldump --opt db_name>db_namesql

3、启用新的更新日志

shell>mysqladmin flush-logs

这样可以记录你备份后的数据改变为恢复数据准备。

4、解除表的读锁

mysql>UNLOCK TABLES;

为了加速上述过程，你可以这样做：

shell> mysqldump --lock-tables --opt db_name>db_namesql; mysqladmin flush-logs

但是这样可能会有点小问题。上命令在启用新的更新日志前就恢复表的读锁，

在更新繁忙的站点，可能有备份后的更新数据没有记录在新的日志中。

现在恢复上面备份的数据库

1、对涉及的表使用写锁

mysql>LOCK TABLES tbl1 WRITE,tbl1 WRITE,…

2、恢复备份的数据

shell>mysql db_name < db_namesql

3、恢复更新日志的内容

shell>mysql --one-database db_name < hostnamennn

假设需要使用的日志名字为hostnamennn

4、启用新的更新日志

shell>mysqladmin flush-logs

5、解除表的写锁

mysql>UNLOCK TABLES;

希望上面的例子能给你启发，因为备份数据的手法多种多样，你所使用的和上面所述可能大不一样，但是对于备份和恢复中，表的锁定、启用新的更新日志的时机应该是类似的，仔细考虑这个问题。

MySQL数据库优化:

选择InnoDB作为存储引擎

大型产品的数据库对于可靠性和并发性的要求较高，InnoDB作为默认的MySQL存储引擎，相对于MyISAM来说是个更佳的选择。

优化数据库结构

组织数据库的schema、表和字段以降低I/O的开销，将相关项保存在一起，并提前规划，以便随着数据量的增长，性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化，表的主键应尽可能短。·对于InnoDB表，主键所在的列在每个辅助索引条目中都是可复制的，因此如果有很多辅助索引，那么一个短的主键可以节省大量空间。

仅创建你需要改进查询性能的索引。索引有助于检索，但是会增加插入和更新 *** 作的执行时间。

InnoDB的ChangeBuffering特性

InnoDB提供了changebuffering的配置，可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表 *** 作和大量的I/O，以保证辅助索引保持最新。当相关页面不在缓冲池里面时，InnoDB的changebuffer将会更改缓存到辅助索引条目，从而避免因不能立即从磁盘读取页面而导致耗时的I/O *** 作。当页面被加载到缓冲池时，缓冲的更改将被合并，更新的页面之后会刷新到磁盘。这样做可提高性能，适用于MySQL55及更高版本。

InnoDB页面压缩

InnoDB支持对表进行页面级的压缩。当写入数据页的时候，会有特定的压缩算法对其进行压缩。压缩后的数据会写入磁盘，其打孔机制会释放页面末尾的空块。如果压缩失败，数据会按原样写入。表和索引都会被压缩，因为索引通常是数据库总大小中占比很大的一部分，压缩可以显著节约内存，I/O或处理时间，这样就达到了提高性能和伸缩性的目的。它还可以减少内存和磁盘之间传输的数据量。MySQL51及更高版本支持该功能。

注意，页面压缩并不能支持共享表空间中的表。共享表空间包括系统表空间、临时表空间和常规表空间。

使用批量数据导入

在主键上使用已排序的数据源进行批量数据的导入可加快数据插入的过程。否则，可能需要在其他行之间插入行以维护排序，这会导致磁盘I/O变高，进而影响性能，增加页的拆分。关闭自动提交的模式也是有好处的，因为它会为每个插入执行日志刷新到磁盘。在批量插入期间临时转移唯一键和外键检查也可显著降低磁盘I/O。对于新建的表，最好的做法是在批量导入后创建外键/唯一键约束。

一旦你的数据达到稳定的大小，或者增长的表增加了几十或几百兆字节，就应该考虑使用OPTIMIZETABLE语句重新组织表并压缩浪费的空间。对重新组织后的表进行全表扫描所需要的I/O会更少。

优化InnoDB磁盘I/O

增加InnoDB缓冲池大小可以让查询从缓冲池访问而不是通过磁盘I/O访问。通过调整系统变量innodb_flush_method来调整清除缓冲的指标使其达到最佳水平。

MySQL的内存分配

在为MySQL分配足够的内存之前，请考虑不同领域对MySQL的内存需求。要考虑的关键领域是：并发连接——对于大量并发连接，排序和临时表将需要大量内存。在撰写本文时，对于处理3000+并发连接的数据库，16GB到32GB的RAM是足够的。

内存碎片可以消耗大约10%或更多的内存。像innodb_buffer_pool_size、key_buffer_size、query_cache_size等缓存和缓冲区要消耗大约80%的已分配内存。

日常维护

定期检查慢的查询日志并优化查询机制以有效使用缓存来减少磁盘I/O。优化它们，以扫描最少的行数，而不是进行全表扫描。

其他可以帮助DBA检查和分析性能的日志包括：错误日志、常规查询日志、二进制日志、DDL日志(元数据日志)。

定期刷新缓存和缓冲区以降低碎片化。使用OPTIMIZETABLE语句重新组织表并压缩任何可能被浪费的空间。

首先，你这个数据确实太多了，应该考虑使用高速磁盘阵列，甚至考虑小型机，以及专业的数据库系统。

其次，如果你的数据库变化不大，可以考虑增加索引，特别是在product_detailcreat_dt 这样的数据分散字段上建立索引，能明显提高效率。如果经常都有更新，索引就不宜过多，否则插入一条数据会非常慢。

如果你的应用非常复杂，数据在大量更新，又需要快速查询，有一些用空间换时间的办法，比如把数据库按照一定规则分在不同的服务器上，查询的时候先对条件进行判断，再提交给不同的服务器进行查询。数据库分片的方法许多，例如你可以按照时间，把每一天的数据存放在不同服务器里面，程序判断条件之后，调用对应的服务器进行查询。

空间换时间有一个典型的办法，就是把两个表合并起来，查询的时候就无需关联。

以上就是关于问个mysql优化问题全部的内容，包括:问个mysql优化问题、怎样提高数据库的性能、什么是MySql数据库等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！