求高手优化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时候在使用Access文件的时候，随着增删改的不断的连续，会导致文件越来越大。即使手动删除或者使用delete语句删除了大量的数据记录，会发现文件的大小依然没有减掉，而且随着你再往里写数据，又会增大。

2产生这个现象的原因跟Access本身的机制有关，具体也不清楚，好像是有什么历史记录还是什么存储碎片。ACCESS数据库在进行删除 *** 作后，并不从该数据库中把数据清除掉，而是删除其索引相关的东西，虽然显示不出来，但是那些东西还是在文件中存在的，所以会引起ACCESS数据库文件越来越大。即使是我们不通过代码来访问access文件，而只是通过用户界面访问，随着文件的增大，也会带来一系列的问题。其症状包括：对象可能打开得更慢，查询可能比正常情况下运行的时间更长，各种典型 *** 作通常似乎也需要使用更长时间。更何况如果在网站应用中，采用的是Access作为数据库的话，这里就有了性能上的问题。文件越来越大，会影响查询的速度，而且ACCESS是采用独占方式工作的,也就是说一次只能一个进程打开这个数据库执行 *** 作,如果是多个用户的话就要"排队"了,所以ACCESS数据库如果变为很大的话,执行一个查询时间就会变长,而进程"排队"的等待时间也就会变得很久,专业型的数据库就不同，可以同时接收多个并发的访问，可以采用SQL数据库或其它大型并发数很强的数据库。

3但是很多时候我们是需要Access文件，往不同的地方拷贝的，比如说，一个Server上生成了一个Access文件，需要拷贝到另外的Server上，而且Server间如果网速不是很好的话，会需要很长的时间来传输这个文件。所以这时候我们希望这个文件在内容不变的前提下，越小越好。所以我们可以去除这个Access的冗余信息。

4Office Access本身就有这种功能，我们可以通过菜单找到这个工具，然后单击这个图标手动压缩。

5执行以下这几句代码就可以了。

首先引用C:\Program Files\Common Files\System\ado\msadoxdll,该DLL包含ADOX命名空间; 

接着引用C:\Program Files\Common Files\System\ado\msjrodll,该DLL包含JRO命名空间 

注意:如，导入dll不成功，手动把com组件 导入为 net组件，在用vsnet工具导入

///压缩修复ACCESS数据库,mdbPath为数据库绝对路径

        public void Compact(string mdbPath)

        {

            if (!FileExists(mdbPath)) //检查数据库是否已存在

            {

                throw new Exception("目标数据库不存在,无法压缩");

            }

            //声明临时数据库的名称

            string temp = DateTimeNowYearToString();

            temp += DateTimeNowMonthToString();

            temp += DateTimeNowDayToString();

            temp += DateTimeNowHourToString();

            temp += DateTimeNowMinuteToString();

            temp += DateTimeNowSecondToString() + "bak";

            temp = mdbPathSubstring(0, mdbPathLastIndexOf("\\") + 1) + temp;

            //定义临时数据库的连接字符串

            string temp2 = "Provider=MicrosoftJetOLEDB40;Data Source=" + temp;

            //定义目标数据库的连接字符串

            string mdbPath2 = "Provider=MicrosoftJetOLEDB40;Data Source=" + mdbPath + ";Jet OLEDB:Database Password=l1epc2";

            //创建一个JetEngineClass对象的实例

            JetEngineClass jt = new JetEngineClass();

            //使用JetEngineClass对象的CompactDatabase方法压缩修复数据库

            jtCompactDatabase(mdbPath2, temp2);

            //拷贝临时数据库到目标数据库(覆盖)

            FileCopy(temp, mdbPath, true);

            //最后删除临时数据库

            FileDelete(temp);

        }

确定网速没问题的话，用的又是存储过程，服务器要处理rollback,log之类的 *** 作会变慢，但是不至于慢这么多，你检查一下防火墙和杀毒软件，把他们关了看看会不会变快。能想到的就这么多了。刚刚给你查了下，禁用DNS解析，连接速度会快很多。不妨试一下，如果还慢的话，建议用缓存吧，比如hibernate框架

数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。

可以做表拆分，减少单表字段数量，优化表结构。

在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。

主要两种拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基于列字段进行的。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。 一般是针对 那种 几百列的大表，也避免查询时，数据量太大造成的“跨页”问题。

垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Product一个库，订单Order一个库。 切分后，要放在多个服务器上，而不是一个服务器上。为什么？ 我们想象一下，一个购物网站对外提供服务，会有用户，商品，订单等的CRUD。没拆分之前， 全部都是落到单一的库上的，这会让数据库的单库处理能力成为瓶颈。按垂直分库后，如果还是放在一个数据库服务器上， 随着用户量增大，这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧。 所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题。

数据库业务层面的拆分，和服务的“治理”，“降级”机制类似，也能对不同业务的数据分别的进行管理，维护，监控，扩展等。 数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的。 数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈。

水平分表

针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

水平分库分表切分规则

1 RANGE

从0到10000一个表，10001到20000一个表；

2 HASH取模

一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。

3 地理区域

比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。

4 时间

按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

事务支持

分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

跨库join

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。

ID问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由

一些常见的主键生成策略

UUID

使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。

Twitter的分布式自增ID算法Snowflake

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。

垂直拆分

垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表

通常我们按以下原则进行垂直拆分:

把不常用的字段单独放在一张表;

把text，blob等大字段拆分出来放在附表中;

经常组合查询的列放在一张表中;垂直拆分更多时候就应该在数据表设计之初就执行的步骤，然后查询的时候用join关键起来即可;

水平拆分

水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。

水平拆分的一些技巧

1 拆分原则

通常情况下，我们使用取模的方式来进行表的拆分;比如一张有400W的用户表users，为提高其查询效率我们把其分成4张表

users1，users2，users3，users4

通过用ID取模的方法把数据分散到四张表内Id%4+1 = [1,2,3,4]

这里是个小哈希，然后查询,更新,删除也是通过取模的方法来查询

$_GET['id'] = 17,

17%4 + 1 = 2,

$tableName = 'users''2'

Select from users2 where id = 17;

在insert时还需要一张临时表uid_temp来提供自增的ID,该表的唯一用处就是提供自增的ID;

insert into uid_temp values(null);

得到自增的ID后,又通过取模法进行分表插入;

注意,进行水平拆分后的表,字段的列和类型和原表应该是相同的,但是要记得去掉auto_increment自增长

另外

部分业务逻辑也可以通过地区，年份等字段来进行归档拆分;

进行拆分后的表，只能满足部分查询的高效查询需求，这时我们就要在产品策划上，从界面上约束用户查询行为。比如我们是按年来进行归档拆分的,这个时候在页面设计上就约束用户必须要先选择年,然后才能进行查询;

在做分析或者统计时，由于是自己人的需求,多点等待其实是没关系的,并且并发很低,这个时候可以用union把所有表都组合成一张视图来进行查询,然后再进行查询;

Create view users as select from users1 union select from users2 union

首先应该确定是谁慢的，往往是程序处理方面的问题而不是数据库的问题。

程序方面应该尽可能的减少数据查询返回的内容，比如可以查询返回ID，然后再根据ID一条一条的查询具体内容，看似慢了，在数据量达的时候快很多

对于数据可以参照下面几点

1、优化SQL语句，SQL语句对查询速度影响最大

2、对于经常查询的字段作索引。但是这样会增加修改时的压力

4、优化SQLServer，比如给其分配固定的内存，预先分配查询内存，调整CPU使用率等。

5、优化硬件资源，比如使用更高的服务器或者硬盘，独立安排数据库的数据文件和索引文件，将数据文件分布于不同的物理硬盘上等等

6、考虑使用分布数据库或者对大表进行拆分

另外，2G的数据库应该不算很大了，我处理过18G的数据库，8000万条记录，查询速度可以被接受

是什么网络啊 连局域网络的 还是 外部网络 好象是中病毒了 （局域网按理说是中不了病毒的，但是在单位有的人总爱拿U盘等在工作站导资料 就中了）只是电脑慢也说不准有其他毛病，但我建议买本 新出 的〈电脑迷〉等书 用他带的光盘启动电脑在dos下杀毒

以上就是关于求高手优化MySQL数据库，数据库反应太慢。全部的内容，包括:求高手优化MySQL数据库，数据库反应太慢。、怎么解决ACCESS数据库太大造成运行慢的问题、如何解决服务器数据库查询速度慢等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！