2

我需要数据库专家的帮助。

在 MySQL 中导出为 SQL 文件时，我有一个超过 1.5 GB 的大型数据库。

我现在面临的问题是，对包含数百万数据的 stats 等表的查询只会使服务器崩溃。

我现在正在考虑一些解决方案，我倾向于为大型表实现 Redis，然后才能让 Redis 和 MySQL 一起工作。我认为我应该保留 MySQL，因为它设置了很多复杂的关系，尤其是在定义权限和访问控制列表时。此外，我不确定 Redis 是否可以安全地存储支付等敏感数据。

这是解决问题的最佳方法吗？

我听说的替代方法是 MySQL 分片，我听说它对性能提升非常有效。

在这种情况下你会怎么做？

更新 - 这是我从 MySQLTuner 获得的：

-------- Performance Metrics -------------------------------------------------
[--] Up for: 9d 1h 9m 33s (98M q [126.517 qps], 2M conn, TX: 354B, RX: 15B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 232.0M global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 647.2M (10% of installed RAM)
[OK] Slow queries: 0% (876/98M)
[!!] Highest connection usage: 100%  (152/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/294.2M
[OK] Key buffer hit rate: 100.0% (148B cached / 2M reads)
[OK] Query cache efficiency: 81.0% (64M cached / 79M selects)
[!!] Query cache prunes per day: 36845
[OK] Sorts requiring temporary tables: 0% (27 temp sorts / 7M sorts)
[!!] Joins performed without indexes: 8358004
[!!] Temporary tables created on disk: 44% (8M on disk / 18M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (400 open / 266K opened)
[OK] Open file limit used: 38% (398/1K)
[OK] Table locks acquired immediately: 99% (42M immediate / 42M locks)
[OK] InnoDB data size / buffer pool: 67.8M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Reduce or eliminate persistent connections to reduce connection usage
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    max_connections (> 151)
    wait_timeout (< 28800)
    interactive_timeout (< 28800)
    query_cache_size (> 64M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 400)
4

2 回答 2

2

没有一个普遍的限制，但 1.5GB 甚至不应该被视为大数据。您没有提供 TPS（每秒事务数）的数量，这可能表明您的工作量。

但是，与尝试优化 RDBMS 相比，切换到非关系解决方案会导致更多问题。所以，你应该问自己：

  • 哪些查询会破坏服务器？
  • 您的查询是否使用了良好的索引？
  • 您的长时间运行的查询是否会锁定表？
  • 你的服务器配置好了吗？您是否将 innodb_buffer_pool_size 设置为使用 80% 的可用内存？看看 Percona 的这些幻灯片：http ://www.percona.com/files/presentations/WEBINAR2012-03-Optimizing-MySQL-Configuration.pdf
  • 您是否正在使用使系统变慢的东西？例如，SELinux 在您需要良好性能的地方很糟糕。

如果所有答案都是“是”，则考虑使用其他解决方案：

  • 升级硬件（按重要性顺序：更多 RAM、更快的磁盘、更多的 CPU 和快速 BUS）
  • MySQL 分区
  • XtraDB 集群，来自 Percona
  • Shard Query 存储引擎，它使一些分片和负载平衡
于 2013-05-22T15:38:08.633 回答
0

1.5G的数据不是大数据，MySql如果配置正确是可以处理的。

因此，在您查看其他任何内容之前，请确保您的 MySql 数据库已尝试并排除了此列表中的所有内容：

  • 你已经调整了你的mysql配置（默认很烂）
  • 您正在使用索引
  • 您优化了查询（确保您实际使用索引）
  • 你可以使用尽可能多的内存

在此列表的末尾，您将了解更多有关 MySql 的信息，并且您可能不需要向堆栈中添加额外的组件。（或者您可以聘请 DBA 并获得相同的结果）

于 2013-05-22T15:34:52.260 回答