mysql表中的数据非常大。即使是 select 语句也需要很多时间答案

【问题标题】：Very big data in mysql table. Even select statements take much timemysql表中的数据非常大。即使是 select 语句也需要很多时间
【发布时间】：2012-12-28 09:50:30
【问题描述】：

我正在开发一个数据库，它是一个相当大的数据库，有 13 亿行和大约 35 列。这是我检查表状态后得到的结果：

Name:Table Name
Engine:InnoDB
Version:10
Row_format:Compact
Rows:12853961
Avg_row_length:572
Data_length:7353663488
Max_data_length:0
Index_length:5877268480
Data_free:0
Auto_increment:12933138
Create_time:41271.0312615741
Update_time:NULL
Check_time:NULL
Collation:utf8_general_ci
Checksum:NULL
Create_options:
Comment:InnoDB free: 11489280 kB

我面临的问题是，即使是单个选择查询也需要花费太多时间来处理，例如查询 Select * from Table_Name limit 0,50000 大约需要 2.48 分钟这是预期的吗？

我必须制作一份报告，其中我必须使用整个历史数据，即整个 13 亿行。我可以逐批执行此操作，但随后我将不得不一次又一次地运行花费太多时间的查询。

当简单查询花费这么多时间时，我无法执行任何其他需要连接和案例语句的复杂查询。

【问题讨论】：

我们可以看看您的数据库架构吗？运行DESC Table\ Name
在表中添加索引，在 where 子句中使用索引列。
不要使用 * 进行选择，只提取您想要的列。
我不确定 mysql 配置，但为了获得更快的 sql 查询运行解释计划 - 查看所有成本和内存在哪里。贴在这里，我们会告诉你如何让sql查询更快
在您的表上尝试范围分区。不会影响您的数据。可能会提高您的表现

标签： mysql database performance query-optimization reporting

【解决方案1】：

一种常见的做法是，如果您有大量数据，您...

不应该SELECT *：你应该只选择你想要的列
应该将您的获取范围限制为一个较小的数字：我敢打赌您不会同时处理 50000 条记录。尝试批量获取。

【讨论】：

我必须制作一份报告，其中我必须使用整个 13 亿行的整个历史数据。我可以逐批执行此操作，但随后我将不得不按时应用查询，这又会花费太多时间，这会增加我必须处理的大量批次。真的卡在这里
报告查询总是花费很多时间。真正的解决方案是，定义一个可以从您的数据中获取所有有用数据（没有垃圾）的查询。 如果适用，添加索引
create table interm1 as select device_uuid,name from Table name 这样的查询大约需要 20-30 分钟。

【解决方案2】：

许多数据库管理员面临的常见问题。解决方案：缓存。

将查询分解为更简单和更小的查询。使用 Memcached 或其他缓存技术和工具 Memcached 保存键值对，检查 memcache 中的数据。如果可用，请使用它。如果不从数据库中获取它，然后使用并缓存。接下来，数据将从 cahe 获得。

您将不得不开发自己的逻辑并更改一些查询。此处提供 Memcached：

http://memcached.org/

网上有很多教程

【讨论】：

我不建议使用 memcached 来“隐藏”设计不良（没有适当索引）的表。好像“把垃圾藏在地毯下”
no..databses 很慢！！缓存速度很快..从 facebook 到 twitter..所有主要网站都使用 memcached。
我每天都使用 memcached，但是一旦我对查询进行了微调，我就会使用 memcached，如果你想要 FRESH 数据（报告数据、实时统计数据等），memcached 就没用了
缓存对于报表应用程序来说是无用的。 1. 他不会经常访问相同的数据。 2.缓存对于Web应用访问常用数据很有用

【解决方案3】：

在你的 my.conf 中启用最多 N 秒的慢查询，然后执行一些查询并观察这个日志，这会给你一些线索，也许你可以在这个表中添加一些索引。

或使用 EXPLAIN 进行一些查询。 http://hackmysql.com/case1

【讨论】：

13 亿行的查询可能需要超过 1 秒。所以，慢查询日志会记录他所有的上报SQL语句。
信不信由你，我处理了一些具有这么多行的表，并且选择时间不到 1 秒：D

【解决方案4】：

一个通常很容易获胜的快速注释...

如果您有任何列是大文本块，请尝试选择除这些字段之外的所有内容。我已经看到 varchar(max) 字段绝对会降低查询效率。

【讨论】：

【解决方案5】：

您有一个非常宽的平均行大小和 35 列。您可以尝试对表进行垂直分区，即将表拆分为较小的表，这些表彼此 1:1 相关，其中包含表中的列子集。 InnoDB 将行存储在页面中，对于非常宽的行效率不高。

如果数据是仅附加的，请考虑查看 ICE。

您可能还会查看 TokuDB，因为它支持良好的压缩。

您可以考虑使用分区和 Shard-Query (http://code.google.com/p/shard-query) 来并行访问数据。您还可以使用 Shard-Query 在多个服务器上拆分数据以实现并行性。

【讨论】：

【解决方案6】：

尝试添加 WHERE 子句：WHERE 1=1 如果它没有产生任何效果，那么您应该将引擎类型更改为 MyISAM。

【讨论】：

似乎不相关。顺便说一句，用这么大的数据量更换 DB Engine 需要很长时间。
我无法更改我的数据库。我相信mySql一定有一些大表的解决方案
MyISAM 的读取速度比 InnoDB 快。我认为最好用有很多行的表进行测试，然后给出正确的意见。
过去我也遇到过类似的问题。添加 WHERE 1=1 可以提高时间执行，但将其引擎类型更改为 MyISAM 会提高更多。
Where 1=1 对所有条件都为真，并且将具有与没有 Where 类似的执行计划。试试 EXPLAIN 你会看到的。