mysql查詢 中，in 與 or 的效率差不多，關鍵是否有索引。mysql in 查詢的數據類型也會導致查詢結果不相同，一般varchar 和int 查詢時間相差不大，效率幾乎相同。

如果in里面有之查詢。建議使用join 替換in+子查詢。使用連接（JOIN）來代替子查詢(Sub-Queries) mysql優化系列記錄。

再說一下不同引擎的優化，myisam讀的效果好，寫的效率差，這和它數據存儲格式，索引的指針和鎖的策略有關的，它的數據是順序存儲的（innodb數據存儲方式是聚簇索引），他的索引btree上的節點是一個指向數據物理位置的指針，所以查找起來很快，（innodb索引節點存的則是數據的主鍵，所以需要根據主鍵二次查找）；myisam鎖是表鎖，只有讀讀之間是并發的，寫寫之間和讀寫之間（讀和插入之間是可以并發的，去設置concurrent_insert參數，定期執行表優化操作，更新操作就沒有辦法了）是串行的，所以寫起來慢，并且默認的寫優先級比讀優先級高，高到寫操作來了后，可以馬上插入到讀操作前面去，如果批量寫，會導致讀請求餓死，所以要設置讀寫優先級或設置多少寫操作后執行讀操作的策略;myisam不要使用查詢時間太長的sql，如果策略使用不當，也會導致寫餓死，所以盡量去拆分查詢效率低的sql,



innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在數據記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以并發的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一致性的非鎖定快照讀，也就是根據數據庫隔離級別策略，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是當前讀，讀取原始行；因為普通讀與寫不沖突，所以innodb不會出現讀寫餓死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競爭相同鎖的情況就少，就增加了并發處理，所以并發讀寫的效率還是很優秀的，問題在于索引查詢后的根據主鍵的二次查找導致效率低；