邏輯刪除的字段在查詢的時候的性能影響（Version3.1.0）
TbUser?one?=?new?LambdaQueryChainWrapper<>(tbUserMapper) ????????.select(TbUser::getUserId,?TbUser::getNickname) ????????.eq(TbUser::getUserId,?1239563848215904258L).one();
邏輯刪除的字段是deleted
但是我發(fā)現(xiàn)執(zhí)行的時候打印的SQL是
SELECT?user_id,nickname?FROM?tb_user?WHERE?deleted=0?AND?user_id?=??
deleted條件自動放在了最前面，這樣對大數(shù)據(jù)量查詢性能不會有負面影響嗎？
2020-03-17
? ? ? ?按照我看到過的文章，說sql是從右向左解析的，能夠排除最大量數(shù)據(jù)的條件應(yīng)該放在最右面。你那句明顯應(yīng)該是user_id?= ？這個條件過濾掉的數(shù)據(jù)最多。單單從這條語句來說，deleted=0放在最前面是對的。但是其他情況則不一定，我目前了解的mp，這個邏輯刪除字段的位置還不能修改，你可以去MP官方群里咨詢一下作者，看看能否解決?；蛘咴趃ithub或gitee上提問。
2020-03-27
以本人愚見，MySQL對語句的執(zhí)行是有優(yōu)化的。MySQL會對執(zhí)行的語句進行處理，生成多種執(zhí)行方案，然后選取成本最低的方案。下面是兩條語句的執(zhí)行計劃：
mysql> explain SELECT * FROM user WHERE ?id = 1088248166370832385 and deleted =0\G
*************************** 1. row ***************************
? ? ? ? ? id: 1
?select_type: SIMPLE
? ? ? ?table: user
? partitions: NULL
? ? ? ? type: const
possible_keys: PRIMARY
? ? ? ? ?key: PRIMARY
? ? ?key_len: 8
? ? ? ? ?ref: const
? ? ? ? rows: 1
? ? filtered: 100.00
? ? ? ?Extra: NULL
mysql> explain SELECT * FROM user WHERE deleted=0 AND id = 1088248166370832385\G
*************************** 1. row ***************************
? ? ? ? ? id: 1
?select_type: SIMPLE
? ? ? ?table: user
? partitions: NULL
? ? ? ? type: const
possible_keys: PRIMARY
? ? ? ? ?key: PRIMARY
? ? ?key_len: 8
? ? ? ? ?ref: const
? ? ? ? rows: 1
? ? filtered: 100.00
? ? ? ?Extra: NULL
兩個的執(zhí)行計劃是一樣的。它們的效率應(yīng)該會相等吧。
2020-03-17
你的需求是大數(shù)據(jù)量，那么肯定會分頁，這個時候先后順序其實影響不大。如果非要說性能的話，其實你多了一個deleted=0 條件性能肯定有損耗，因為你這條SQL語句如果沒有邏輯刪除這個功能的話直接走的是主鍵索引user_id(主鍵)當然性能最好。如果對性能問題很介意，你可以自定義SQL查詢，它不走邏輯刪除。其實，邏輯刪除的目的是為了數(shù)據(jù)安全，我們需要做出選擇，在安全和性能中找到平衡。希望可以幫到你。