我的Myqls数据库中有2个数据表，每个数据表都有超过3千万条记录，查询效率很低，有没有什麽好的办法优化

首先换数据库，MySQL处理这个数量级数据比较吃力。推荐你用DB2 或ORACLE

如果不能换，检查一下存储引擎用InnoDB，如果是，检查

innodb_flush_log_at_trx_commit 这个选项，是否是1

如果是1 用SET AUTOCOMMIT = 0 ，提高数据修改速度

PHP优化需要

MySQL Slow Log 分析工具分析日志：mysqldumpslow或mysqlsla比较不错。

Explain/ DESC 分析SQL 的执行情况和SHOW PROCESSLIST

使用SHOW PROCESSLIST 看是否有锁表情况，

设置 mycnf 中的long-query-time 和log-slow-queries 记录服务器那些SQL执行速度比较慢

根据上述情况查看对对应的SQL语句进行优化

优化服务器性能，用RAID5（SAN），加内存本身的升级，提高硬盘I/O性能。

数据库总体性能优化：

数据表最好能拆成小表。

数据库切片，分到不用的服务器上，

数据库访问性能优化

修改mycnf, 下面是影响比较大的：

innodb_flush_log_at_trx_commit 设置为0

如果比下面值大就不用调整了：

query_cache_size 设置为16M

sort_buffer_size 设置为16M

record_buffer 设置为16M

key_buffer_size 设置为8M

innodb_buffer_pool_size 设置为32M

下面是建议设置的

table_cache 设置为512

read_buffer_size 设置为16M

myisam_sort_buffer_size设置为16M

innodb_additional_mem_pool_size 设置为128M

innodb_log_file_size 设置为256M

innodb_log_buffer_size设置为8M

数据库表优化，

1 建立相应的INDEX

2 统一编码，MySQL的默认编码是Latin1，不支持中文，需要把数据库的默认编码修改为gbk或者utf8

show variables like 'character%' 查看

另外表的编码也要与数据库统一

这需要根据导致

运行速度

不高的原因来考虑。

如果是因为数据库的关系，可以将不经常变化的却经常需要用到的数据在第一次读出来的时候保存到内存中，以后就不用再去读取了。

除此以外就是数据库连接的优化了，比如做好索引、分页读取等。

很多应用往往只展示最新或最热门的几条记录，但为了旧记录仍然可访问，所以就需要个分页的导航栏。然而，如何通过MySQL更好的实现分页，始终是比较令人头疼的问题。虽然没有拿来就能用的解决办法，但了解数据库的底层或多或少有助于优化分页查询。

我们先从一个常用但性能很差的查询来看一看。

SELECT

FROM city

ORDER BY id DESC

LIMIT 0, 15

这个查询耗时000sec。So，这个查询有什么问题呢？实际上，这个查询语句和参数都没有问题，因为它用到了下面表的主键，而且只读取15条记录。

CREATE TABLE city (

id int(10) unsigned NOT NULL AUTO_INCREMENT,

city varchar(128) NOT NULL,

PRIMARY KEY (id)

) ENGINE=InnoDB;

真正的问题在于offset(分页偏移量)很大的时候，像下面这样：

SELECT

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

上面的查询在有2M行记录时需要022sec，通过EXPLAIN查看SQL的执行计划可以发现该SQL检索了100015行，但最后只需要15行。大的分页偏移量会增加使用的数据，MySQL会将大量最终不会使用的数据加载到内存中。就算我们假设大部分网站的用户只访问前几页数据，但少量的大的分页偏移量的请求也会对整个系统造成危害。Facebook意识到了这一点，但Facebook并没有为了每秒可以处理更多的请求而去优化数据库，而是将重心放在将请求响应时间的方差变小。

对于分页请求，还有一个信息也很重要，就是总共的记录数。我们可以通过下面的查询很容易的获取总的记录数。

SELECT COUNT()

FROM city;

然而，上面的SQL在采用InnoDB为存储引擎时需要耗费928sec。一个不正确的优化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能够在分页查询时事先准备好符合条件的记录数，随后只要执行一句 select FOUND_ROWS(); 就能获得总记录数。但是在大多数情况下，查询语句简短并不意味着性能的提高。不幸的是，这种分页查询方式在许多主流框架中都有用到，下面看看这个语句的查询性能。

SELECT SQL_CALC_FOUND_ROWS

FROM city

ORDER BY id DESC

LIMIT 100000, 15;

这个语句耗时2002sec，是上一个的两倍。事实证明使用 SQL_CALC_FOUND_ROWS 做分页是很糟糕的想法。

下面来看看到底如何优化。文章分为两部分，第一部分是如何获取记录的总数目，第二部分是获取真正的记录。

高效的计算行数

如果采用的引擎是MyISAM，可以直接执行COUNT()去获取行数即可。相似的，在堆表中也会将行数存储到表的元信息中。但如果引擎是InnoDB情况就会复杂一些，因为InnoDB不保存表的具体行数。

我们可以将行数缓存起来，然后可以通过一个守护进程定期更新或者用户的某些 *** 作导致缓存失效时，执行下面的语句：

SELECT COUNT()

FROM city

USE INDEX(PRIMARY);

获取记录

下面进入这篇文章最重要的部分，获取分页要展示的记录。上面已经说过了，大的偏移量会影响性能，所以我们要重写查询语句。为了演示，我们创建一个新的表“news”，按照时事性排序(最新发布的在最前面)，实现一个高性能的分页。为了简单，我们就假设最新发布的新闻的Id也是最大的。

CREATE TABLE news(

id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,

title VARCHAR(128) NOT NULL

) ENGINE=InnoDB;

一个比较高效的方式是基于用户展示的最后一个新闻Id。查询下一页的语句如下，需要传入当前页面展示的最后一个Id。

SELECT

FROM news WHERE id < $last_id

ORDER BY id DESC

LIMIT $perpage

查询上一页的语句类似，只不过需要传入当前页的第一个Id，并且要逆序。

SELECT

FROM news WHERE id > $last_id

ORDER BY id ASC

LIMIT $perpage

上面的查询方式适合实现简易的分页，即不显示具体的页数导航，只显示“上一页”和“下一页”，例如博客中页脚显示“上一页”，“下一页”的按钮。但如果要实现真正的页面导航还是很难的,下面看看另一种方式。

SELECT id

FROM (

SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt

FROM news

JOIN (SELECT @cnt:= 0)T

WHERE id < $last_id

ORDER BY id DESC

LIMIT $perpage $buttons

)C

WHERE cnt = 0;

通过上面的语句可以为每一个分页的按钮计算出一个offset对应的id。这种方法还有一个好处。假设，网站上正在发布一片新的文章，那么所有文章的位置都会往后移一位，所以如果用户在发布文章时换页，那么他会看见一篇文章两次。如果固定了每个按钮的offset Id，这个问题就迎刃而解了。Mark Callaghan发表过一篇类似的博客，利用了组合索引和两个位置变量，但是基本思想是一致的。

如果表中的记录很少被删除、修改，还可以将记录对应的页码存储到表中，并在该列上创建合适的索引。采用这种方式，当新增一个记录的时候，需要执行下面的查询重新生成对应的页号。

SET p:= 0;

UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;

当然，也可以新增一个专用于分页的表，可以用个后台程序来维护。

UPDATE pagination T

JOIN (

SELECT id, CEIL((p:= p + 1) / $perpage) page

FROM news

ORDER BY id

)C

ON Cid = Tid

SET Tpage = Cpage;

现在想获取任意一页的元素就很简单了：

SELECT

FROM news A

JOIN pagination B ON Aid=BID

WHERE page=$offset;

还有另外一种与上种方法比较相似的方法来做分页，这种方式比较试用于数据集相对小，并且没有可用的索引的情况下—比如处理搜索结果时。在一个普通的服务器上执行下面的查询，当有2M条记录时，要耗费2sec左右。这种方式比较简单，创建一个用来存储所有Id的临时表即可(这也是最耗费性能的地方)。

CREATE TEMPORARY TABLE _tmp (KEY SORT(random))

SELECT id, FLOOR(RAND() 0x8000000) random

FROM city;

ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;

接下来就可以向下面一样执行分页查询了。

SELECT

FROM _tmp

WHERE OFFSET >= $offset

ORDER BY OFFSET

LIMIT $perpage;

简单来说，对于分页的优化就是。。。避免数据量大时扫描过多的记录。

1、主键就是聚集索引

2、只要建立索引就能显著提高查询速度

3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度

　(四)其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快

2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下

3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个

4 、日期列不会因为有分秒的输入而减慢查询速度

(五)其他注意事项

1 不要索引常用的小型表

2 不要把社会保障号码(SSN)或身份z号码(ID)选作键

3 不要用用户的键

4 不要索引 memo/notes 字段和不要索引大型文本字段(许多字符)

5 使用系统生成的主键

　二、改善SQL语句

1、Like语句是否属于SARG取决于所使用的通配符的类型

2、or 会引起全表扫描

3、非 *** 作符、函数引起的不满足SARG形式的语句

4、IN 的作用相当与OR

5、尽量少用NOT

6、exists 和 in 的执行效率是一样的

7、用函数charindex()和前面加通配符%的LIKE执行效率一样

8、union并不绝对比or的执行效率高

9、字段提取要按照“需多少、提多少”的原则，避免“select ”

10、count()不比count(字段)慢

11、order by按聚集索引列排序效率最高

12、高效的TOP

卡顿问题可能是由于数据库查询效率低下导致的。当数据量达到10万条时，可能需要更多的系统资源来查询和处理数据，并且查询时间也会变得更长。为了解决这个问题，您可以考虑以下几个方面：

1 数据库优化：尝试将数据库表设计优化，包括索引和表结构。使用合适的索引可以加快数据查询的速度，而合理的表结构可以减少查询的开销。

2 缓存：使用缓存可以减少对数据库的查询次数。将热门数据缓存在内存中，可以直接从内存中读取数据，减少数据库的压力。

3 分页查询：将数据分页查询，一次只查询一部分数据，可以减少查询的开销。

4 升级硬件：如果您的服务器硬件配置比较低，可以考虑升级硬件，增加服务器的内存和CPU。

综上所述，卡顿问题可能是由于数据库查询效率低下导致的，可以通过数据库优化、缓存、分页查询和升级硬件等方式来解决。

limit 第一个参数是查询的 开始位置，第二个是查询的行数，跟数值大小没关系，如果你的查询慢，因该检查 表是否有索引，而且 like 查询 在大数据中很影响性能，一般like语句会造成全表扫描

以上就是关于我的Myqls数据库中有2个数据表，每个数据表都有超过3千万条记录，查询效率很低，有没有什麽好的办法优化全部的内容，包括:我的Myqls数据库中有2个数据表，每个数据表都有超过3千万条记录，查询效率很低，有没有什麽好的办法优化、C#软件频繁读数据库，很慢，如何优化、mysql分页显示的问题，查找条件太复杂，很慢，要是用limit分页，进入下一页几乎40秒等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！