MyIASM表小於IASM表，所以使用較少資源。
MyIASM表在不同的平臺上二進制層可移植。
MyIASM擁有更大的鍵碼尺寸，更大的鍵碼上限。
對於MyISAM存儲引擎來說，它的讀鎖和寫鎖是互斥的，從而讀寫操作是串行的。那麼，一個進程請求某個 MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進程先獲得鎖。不僅如此，即使讀請求先到鎖等待隊列，寫請求後 到，寫鎖也會插到讀鎖請求之前！這是因爲MySQL認爲寫請求一般比讀 請求要重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原 因，因爲，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設置來調節MyISAM 的調度行爲。通過指定啓動參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先級降低。通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先級降低，給讀進程一定獲得鎖的機會。
上面已經討論了寫優先調度機制帶來的問題和解決辦法。這 裏還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程“餓死”！因此，應用中應儘量避免出現長時間運行的查詢操作，不要總想用一條SELECT語 句來解決問題，因爲這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每 一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在數據庫空閒時段執行，比如一些定期統計可以安排在夜間執行。
MyIASM表在不同的平臺上二進制層可移植。
MyIASM擁有更大的鍵碼尺寸，更大的鍵碼上限。
對於MyISAM存儲引擎來說，它的讀鎖和寫鎖是互斥的，從而讀寫操作是串行的。那麼，一個進程請求某個 MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進程先獲得鎖。不僅如此，即使讀請求先到鎖等待隊列，寫請求後 到，寫鎖也會插到讀鎖請求之前！這是因爲MySQL認爲寫請求一般比讀 請求要重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原 因，因爲，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設置來調節MyISAM 的調度行爲。通過指定啓動參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先級降低。通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先級降低，給讀進程一定獲得鎖的機會。
上面已經討論了寫優先調度機制帶來的問題和解決辦法。這 裏還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程“餓死”！因此，應用中應儘量避免出現長時間運行的查詢操作，不要總想用一條SELECT語 句來解決問題，因爲這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每 一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在數據庫空閒時段執行，比如一些定期統計可以安排在夜間執行。
