我有一个大约 100 个表的数据库来存储各种信息。
最重要的表是我们的订单表，用于存储客户订单，截至目前已超过 100000 条记录，并且还在不断增长。
该表是我们数据库中查询最多的表，用于获取实时订单仪表板、统计数据、分析等所需的各个部分信息。
我定期监视数据库，并在数据库上启用慢速查询以跟踪问题。
我每天都使用像 mysqltuner 这样的脚本来输出查询。
我还使用 mysqlsla 收集有关我们数据库中前 10 个最慢查询的信息。
sample stat
Count : 11.48k (30.66%)
Time : 19.623758 s total, 1.709 ms avg, 239 µs to 2.475017 s max (18.64%)
95% of Time : 5.246833 s total, 481 µs avg, 239 µs to 1.095 ms max
Lock Time (s) : 14.460071 s total, 1.259 ms avg, 53 µs to 2.462555 s max (41.38%)
95% of Lock : 806.43 ms total, 74 µs avg, …我们有一个 MySQL 5.0 服务器，以 MyISAM 的形式运行所有表。我们有两个奴隶，在上个月，我们已经升级到 MySQL 5.5。他们的表也仍然是 MyISAM。
我原来的计划是把5.0的master升级到5.5，然后转成InnoDB。现在我想知道，在升级之前开始是否更有意义？我一直很谨慎，因为我听说 5.5 下的 InnoDB 比 5.0 下的 InnoDB 快得多。这是没有根据的，我现在应该开始吗？
我不确定这个问题的答案是对还是错，因为我认为这在很大程度上取决于情况，但为了心理锻炼，我还是继续问吧：
我的数据库中有一个 MyISAM 表，它位于我的站点的中心。围绕它创建了许多参考表，还有许多其他表直接链接到该表中的行 ID。该表大约有 260k 行，有 28 个字段，其中大部分是 varchars 和 ints。我有大约 15 个索引（数据大约 70 MiB，索引大约 80 MiB）。每天可能有数百次写入，而读取数以万计。我的数据库位于 SSD 驱动器上。
现在我的问题是；将此表更改为 InnoDB 表是否有益？我正在努力扩展我的系统以包括 API 流量，这意味着该表甚至会被查询更多，我想确保一切运行尽可能顺利。因此，我有点倾向于将其转换为 InnoDB。但是，由于该表需要许多索引，我认为 MyISAM 可能会更有效地工作。谁能帮我下定决心？提前致谢1
我很久以前就添加了索引，并且我对 PHP 代码库进行了一些更改，因此可能有些索引已经过时，但总体而言；是的，它们都被使用了。我在表上运行了许多不同类型的查询。不同的查询，不同的索引。但是我在这里的主要问题不涉及表读取性能，而是它如何处理许多索引。InnoDB 索引与数据一起“离开”/存储，而不是 MyISAM 的密钥文件原则。我只是担心这可能会导致足够的性能下降不会超过表锁定问题。
我有一个关于 MySQL 锁定和事务管理的问题。我的问题是 ..mysql 是否锁定了我在事务中执行选择/更新的元组/表？
我需要对 mysql 服务器进行性能调整并需要帮助。
我有一个专用于 MySQL 的 16G 服务器，其中有 1 个 MyISAM 表，其中大约有 200 万行，可以获取大量流量。同一个数据库上还有大约 100 个其他 innodb 表。MyISAM 表几乎是只读的，用户使用它进行搜索。
服务器的 max_connection 值为 800，在大约 300 个并发用户的负载测试下，查询时间开始显着增加。在没有负载的情况下，查询需要大约 500 毫秒才能运行。
目标是显着提高 MyISAM 表上的搜索性能。
表的大小（以 MB 为单位）：
data_size index_size total engine
8991 6920 15911 InnoDB
1110 718 1829 MyISAM
以下是我的设置：
connect_timeout 10
innodb_additional_mem_pool_size 24117248
innodb_buffer_pool_size 12G
innodb_commit_concurrency 0
innodb_flush_log_at_trx_commit 1
innodb_log_buffer_size 11534336
innodb_log_file_size 449839104
innodb_open_files 300
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
join_buffer_size 131072
key_buffer_size 2147483648
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
max_allowed_packet 134217728
max_connections 800 …