在MySQL 5.6.41版的時候，我做過MyISAM與InnoDB「儲存引擎速度評比」的測試實驗。使用的是完全相同的資料庫。只有儲存格式不同而已。發現比較新的InnoDB竟然比MyISAM慢了170倍！
MySQL資料庫儲存引擎MyISAM只要0.01秒，InnoDB卻需要1.7秒，竟然慢了170倍！
MySQL原廠的Oracle宣稱MySQL 8.0的速度可以比MySQL 5.7更快2倍。那麼，在目前最新版本的MySQL 8.0.16的情況下，重做一次MyISAM與InnoDB「儲存引擎速度評比」的測試實驗，會得到什麼樣的結果？
使用的測試指令是insoler首頁與相簿首頁的最新照片的SELECT搜尋資料指令：
- SELECT `bx_photos_main`.`ID` as `id`, `bx_photos_main`.`Title` as `title`, `bx_photos_main`.`Ext`, `bx_photos_main`.`Uri` as `uri`, `bx_photos_main`.`Date` as `date`, `bx_photos_main`.`Size` as `size`, `bx_photos_main`.`Views` as `view`, `bx_photos_main`.`Rate`, `bx_photos_main`.`RateCount`, `bx_photos_main`.`Hash`, `bx_photos_main`.`ID`, `sys_albums_objects`.`id_album`, `bx_photos_main`.`Owner` as `ownerId`, `sys_albums`.`AllowAlbumView`, `Profiles`.`NickName` as `ownerName` FROM `bx_photos_main` left JOIN `sys_albums_objects` ON `sys_albums_objects`.`id_object`=`bx_photos_main`.`ID` left JOIN `sys_albums` ON `sys_albums`.`ID`=`sys_albums_objects`.`id_album` left JOIN `Profiles` ON `Profiles`.`ID`=`bx_photos_main`.`Owner` WHERE 1 AND `bx_photos_main`.`Status` ='approved' AND `Profiles`.`Status` NOT IN('Rejected','Suspended') AND `sys_albums`.`AllowAlbumView` IN('3','4') AND `sys_albums`.`Status` ='active' AND `sys_albums`.`Type` ='bx_photos' ORDER BY `ID` DESC LIMIT 0, 15
MyISAM儲存引擎「0.0037秒」
這是Dolphin 7.4.2標準的MyISAM儲存引擎。
測試的SELECT搜尋資料指令執行時間是「0.0037秒」！這個速度比MySQL 5.6.41版本當時的速度是：
這個相當複雜的SQL指令的執行的時間是「查詢用了0.0164秒」
所以0.0164秒 / 0.0037秒 = 4.4倍
這個速度比MySQL宣稱的2倍還要快更多，看起來相當令人滿意。但是MyISAM是比InnoDB更老舊的儲存引擎，而且「MySQL 4.1.5開始，InnoDB成為預設的儲存引擎」這已經是「2004/09/21」，也就是15年前的事情！
15年後還繼續使用MyISAM（雖然這個格式有速度快的優點）仍舊不使用「預設的儲存引擎」的InnoDB，感覺上落後資訊科技時代超過15年以上！
InnoDB儲存引擎「0.57秒」
在InnoDB儲存引擎推出15年以後，我想還是轉換到15年前新的InnoDB格式會比較好。所以現在insoler是全部使用InnoDB儲存引擎：
執行完全相同的SELECT搜尋資料指令，時間是「0.5727秒」！這個速度很明顯比MyISAM來說「異常緩慢」！
完全相同的資料內容，只不過是從MyISAM格式（例如Windows的FAT32格式）換成15年前新的InnoDB格式（例如Windows的NTFS格式），儲存的資料內容（儲存的檔案）都完全相同，但是速度竟然是：
0.57秒 / 0.0037秒 = 154倍！
這個速度雖然從MySQL 5.6.41的「170倍」進步到「154倍」，但是兩個格式的速度差異還是太大！我不知道為什麼InnoDB格式為什麼會這麼慢？如果是慢了2〜10倍，可能還可以忍耐。但是慢了「154倍」「170倍」就實在很難忍耐！甚至可以說是「不能原諒」！
經過15年都無法解決的「龜速」問題，我想就算再過10年也不可能讓InnoDB與MyISAM一樣快，甚至是更快！所以只好自己想辦法簡化SELECT查詢指令，讓搜尋速度還可以在接受的範圍內。
目前「MySQL Server 起動後到目前為止的 Max_used_connections 最大同時連接數：126」雖然只有達到設定值max_connections的一半，其實原本max_connections預設值是150，所以126已經非常接近原本的預設值。適度加大到200或是300會比較好。但是不能任意加大到3千、3萬！因為這與可用的「記憶體容量」有關。
