【发布时间】：2014-03-06 08:17:30
【问题描述】：
我知道有很多关于这个主题的信息，但我想我已经尽我所能，并且不知道任何关于提高我的 MySQL 数据库性能的新想法（如果有的话？）。
情况：我使用 eTesting 平台（如果有人知道，请进行 taotesting）。它使用 MySQL 数据库，有 8 个表。目前，其中一张表有约 500k 行。其他的要么是空的，要么有 ~10-15 行。起初 mysql 使用这个平台时性能很糟糕，然后我决定将 MyISAM 表转换为 InnoDB 并进行一些 my.cnf 更改。这似乎提高了性能，但没有我想要的那么多。
服务器有 1 个 CPU / 4 个内核。 6 GB 内存。它不是专用于 MySQL，它还托管 PHP/apache/nginx。
更重要的是，数据库中的选择比插入/更新/删除多 80%。
欢迎任何关于如何进一步（如果可能）改进 mysql 配置的想法。
这是我的.cnf：
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer_size = 32M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 50
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
max_connections = 200
#table_cache = 1M
sort_buffer_size = 1M
read_buffer_size = 1M
join_buffer_size = 1M
#thread_concurrency = 8
max_heap_table_size = 64M
tmp_table_size = 64M
#
# * Query Cache Configuration
#
query_cache_limit = 2M
query_cache_size = 2M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
#log-queries-not-using-indexes
#log = /var/log/mysql/testing_req_nec.log
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem
innodb_buffer_pool_size = 4G
innodb_thread_concurrency = 8
innodb_log_file_size = 1G
innodb_log_buffer_size = 16M
innodb_buffer_pool_instances = 8
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table = 1
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_additional_mem_pool_size = 16M
innodb_max_dirty_pages_pct = 90
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer_size = 16M
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
#open_files_limit = 8192
!includedir /etc/mysql/conf.d/
编辑：
好的，我认为不需要实际数字，因为我说我得到的性能对我来说还不够。我正在使用 Jmeter 进行性能测试。一个例子是：学生可以登录，选择测试，提交他的答案，然后结束测试。我已经尝试与大约 30 名学生一起做这件事，这就是我得到的结果：
登录：~2 秒（最佳情况），8 秒（最坏情况）
选择测试：~5s - 7s（最佳情况），~20s - 25s 最坏情况。
提交问题的答案：~5 - 7s（最佳情况），~30s 最坏情况。
测试结束，和其他提交一样。
现在看我想为更多学生（更多线程）提供最佳案例。问题是这个电子测试平台不使用传统的关系数据库模型（如果你听说过，它使用 RDF 三元组）并将它们存储到 MySQL 表中。有很多查询，一个提交约 80 个查询。如果测试有约 15 个项目，则 1 个学生发送约 2k 个查询。
我已经尝试过 EXPLAIN。真的帮不上忙，因为我无法在不破坏其他所有内容的情况下更改 eTesting 平台源代码，也无法更改表结构（除了更改它的引擎，也许是一些索引？）
编辑： 提交查询示例： http://codeviewer.org/view/code:3d10
表结构： http://codeviewer.org/view/code:3d11
mysql> show variables LIKE '%buffer_pool%';
+------------------------------+------------+
| Variable_name | Value |
+------------------------------+------------+
| innodb_buffer_pool_instances | 8 |
| innodb_buffer_pool_size | 4294967296 |
+------------------------------+------------+
2 rows in set (0.00 sec)
解释一个更复杂的查询：
EXPLAIN SELECT count(*) as count FROM statements WHERE (predicate = 'http://www.tao.lu/Ontologies/TAODelivery.rdf#DeliveryExecutionDelivery' AND (object = 'https://etestas.nec.lt/tao_ssl_dev.rdf#i139266227459751316')) AND subject IN (SELECT subject FROM statements WHERE (predicate = 'http://www.tao.lu/Ontologies/TAODelivery.rdf#DeliveryExecutionSubject' AND (object = 'https://etestas.nec.lt/tao_ssl_dev.rdf#i1392637693114892'))) AND subject IN (SELECT subject FROM statements WHERE predicate = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#type' AND object in ('http://www.tao.lu/Ontologies/TAODelivery.rdf#DeliveryExecution'));
+----+--------------------+------------+----------------+---------------+------+---------+-------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+------------+----------------+---------------+------+---------+-------------+------+-------------+
| 1 | PRIMARY | statements | ref | k_po | k_po | 990 | const,const | 1 | Using where |
| 3 | DEPENDENT SUBQUERY | statements | index_subquery | k_sp,k_po | k_sp | 990 | func,const | 1 | Using where |
| 2 | DEPENDENT SUBQUERY | statements | index_subquery | k_sp,k_po | k_sp | 990 | func,const | 1 | Using where |
+----+--------------------+------------+----------------+---------------+------+---------+-------------+------+-------------+
【问题讨论】：
-
分析查询，发布实际数字而不是“糟糕的表现”，这没有任何意义。使用
EXPLAIN查看您的查询在做什么，当然，设计您的表以便它们可以利用 InnoDB 可以提供的性能。 -
查看我的编辑了解更多信息。
-
您可以打开慢查询日志记录，再次使用 Jmeter 对您的应用程序进行压力测试，一旦完成 - 从日志中提取查询，使用 EXPLAIN 分析它们并在此处发布结果。这些数字对于像你这样的设置来说太大了，你增加了缓冲池（我希望你在那之后重新启动 MySQL 服务器，如果你还没有 - 运行
SELECT variables LIKE '%buffer_pool%'以查看 MySQL 实际分配的内容）。设置看起来不错，问题是幕后发生了什么，500k 行并没有那么多。 -
哦，相信我，我已经重新启动了 MySQL。我已经使用这些配置有一段时间了，而不仅仅是几天的工作。关于慢查询，似乎没有查询时间超过 1 秒，至少根据 MySQL Tuner/tuning prime 的说法。如您所见，慢查询日志已打开。可能我无法再提高性能，也许这就是 eTesting 应用程序所能做的一切。
-
这可能根本不是 MySQL 的错，如果它前面有隧道和用某种脚本语言编写的应用程序，那么它们的响应时间可能会影响性能。但是，使用 InnoDB 的 SELECT 查询通常快如闪电（考虑到您的表构造正确，并具有适当的索引）。
标签： mysql performance innodb