為什麼 MySQL 在 Ubuntu 專用機器上很慢，而在 Ubuntu VM 上卻很快？
我有一台配備 Intel i5、8GB RAM、7200RPM HDD 和 Ubuntu 18.04 作業系統的專用機器。我只安裝了 MySQL-5.7.22，請看本題末尾的配置文件內容。我下載了範例員工數據庫以使用 mysqlslap 測試 MySQL 的性能。（請參閱如何使用 mysqlslap 測量 MySQL 查詢性能）。
在專用的 Ubuntu 上：
以下命令需要 6 秒才能返回結果，而結果顯示執行所有查詢的最大秒數需要 0.286 秒：
mysqlslap --user=root --password --host=localhost --auto-generate-sql --verbose Average number of seconds to run all queries: 0.286 seconds Minimum number of seconds to run all queries: 0.286 seconds Maximum number of seconds to run all queries: 0.286 seconds Number of clients running queries: 1 Average number of queries per client: 0同樣，以下命令需要 1 分 53 秒才能返回結果，而結果顯示執行所有查詢的最大秒數需要 1.576 秒：
mysqlslap --user=root --password --host=localhost --concurrency=50 --iterations=10 --auto-generate-sql --verbose Average number of seconds to run all queries: 1.405 seconds Minimum number of seconds to run all queries: 0.760 seconds Maximum number of seconds to run all queries: 1.576 seconds Number of clients running queries: 50 Average number of queries per client: 0在安裝在 VMWare 中的 Ubuntu 中：
現在在SAME SYSTEM上，因為我用 Ubuntu 雙重啟動了 Windows，我執行 Windows 並在 VMWare 中安裝了 Ubuntu，具有 2GB RAM 和 50GB HDD 以及相同的文件系統 Ext4，我使用相同的 mysql 配置得到以下結果：
以下命令立即返回結果，只要我輸入密碼並按 Enter 鍵，就會顯示結果：
mysqlslap --user=root --password --host=localhost --auto-generate-sql --verbose Average number of seconds to run all queries: 0.002 seconds Minimum number of seconds to run all queries: 0.002 seconds Maximum number of seconds to run all queries: 0.002 seconds Number of clients running queries: 1 Average number of queries per client: 0雖然以下命令需要 2.5 秒才能返回結果：
mysqlslap --user=root --password --host=localhost --concurrency=50 --iterations=10 --auto-generate-sql --verbose Average number of seconds to run all queries: 0.154 seconds Minimum number of seconds to run all queries: 0.131 seconds Maximum number of seconds to run all queries: 0.193 seconds Number of clients running queries: 50 Average number of queries per client: 0查看結果，我迷失了虛擬機中的 MySQL 如何在專用系統中執行緩慢而快速執行。
我的問題是，可能會減慢專用機器中的 MySQL 的可能原因是什麼？我怎樣才能讓它像在 VM 中一樣快？
配置文件：
在帶有 Ubuntu 的 VM 和專用系統中，我使用了相同的預設 MySQL 配置，我沒有更改配置文件中的任何內容。
# # 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. # Here is entries for some specific programs # The following values assume you have at least 32M ram [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 = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover-options = BACKUP #max_connections = 100 #table_open_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 16M # # * 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 #slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2 #log-queries-not-using-indexes # # 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
這可能是由於 VM 配置而不是直接是數據庫問題：假設您使用相同版本的數據庫引擎、相同的數據庫配置、相同的數據和相同的測試腳本，都在相同的作業系統上，物理/virtual 環境是唯一的變數。
我假設基準執行了大量的寫操作？如果是這樣，那麼我懷疑不同之處可能是VMWare正在記憶體發送到虛擬磁碟的寫入（實際上忽略了任何“在讓我繼續之前確保它與物理媒體同步”指令mysql正在發出）在物理設置中的位置它確實在等待數據在各個點被確認寫入。在這兩種情況下，Linux 核心都會認為數據已被寫入，並會告訴 mysql，但 VMWare 提供了寫入記憶體，因此在這種情況下它還沒有到達物理磁碟（只是虛擬磁碟）。
無論是那個還是問題都更進一步，Windows正在記憶體寫入，但告訴VMWare他們已經完成，而他們還沒有完成。在任何一種情況下，差異都不會出現在 mysql 或其配置中。
如果這是一個開發/測試環境，速度提升可能是可取的，但如果它是一個您真正關心數據的生產環境，您應該尋求禁用此行為，因為如果您遇到嚴重的事情，它可能會導致數據損壞停電。
其他可能性：
您使用的是差異磁碟還是其他形式的快照？在這種情況下，vmware 可能正在寫入日誌結構化快照文件而不是 vdisk 文件本身——有效地將隨機寫入轉換為順序寫入。在旋轉表面移動頭驅動器上，這可能會產生巨大的影響。IIRC vmare 也支持壓縮的 vdisk，它也可以是日誌格式的，因此可以有效地將一些隨機寫入模式轉換為順序模式，並減少實際寫入的數量。在這兩種情況下，數據可以安全地完全刷新到磁碟，同時比原始磁碟快得多，這與問題歸結為意外寫入記憶體不同。