select * from order where status!=0 and stuuts!=1
not in/not exists都不是好習慣
可以使用優化為in查詢:
select * from order where status in(2,3)
select * from order where desc like '%xx'
而非前導模糊查詢則可以:
select * from order where desc like 'xx%'
select * from user where *** = 1
原因:性別只有男、女,每次過濾掉的資料很少,不宜使用索引。
經驗上,能過濾80%資料時就可以使用索引。對於訂單狀態,如果狀態值很少,不宜使用索引,如果狀態值很多,能夠過濾大量資料,則應該建立索引。
select * from order where year(date)<='2018'
即使date上建立了索引,也會全表掃瞄,可以優化為值計算:
select * from order where date<=curdate()
或者
select * from order where date<='2018-01-01'
select * from user where uid=?
select * from user login_name = ?
原因 b+樹索引時間複雜度是o(log(n) hash索引時間複雜度是o(1)
單列索引不存null值,復合索引不存全為null的值, 如果允許為null,可能會得到"不符合預期的結果集"
select * from user where name!="xiaoming"
如果name允許為null,索引不儲存null值,結果集中不會包含這些記錄。
所以,請使用not null 約束以及預設值。
使用者中心建立了(login_name,passwd)的復合索引
select * from user where login_name=? and password =?
select * from user where password =? and login_name=?
都會命中索引
select * from user where login_name=?
也能命中索引,滿足復合索引最左字首
select * from user where password=?
不能命中索引,不滿足復合索引最左字首
enum儲存的是tinyint,別再列舉中搞一些「中國」「杭州」「技術部」這樣的字串,字串空間又大,效率又低。
select * from user where login_name=?
可以優化為:
select * from user where login_name=? limit 1
原因是: 知道只有一條結果,但資料庫並不知道,明確告訴它,讓它主動停止游標移動
select * from order where date < = curdate()
這不是乙個好的sql實踐,應該優化為:
$curdate = date('y-m-d');
$res = mysql_query(
'select * from order where date < = $curdate');
原因: 釋放了資料庫的cpu 多次呼叫,傳入的sql相同,才可以利用查詢快取
select * from user where phone=13800001234
使用varchar型別儲存**號碼
與資料庫的記憶體使用量有關
sql優化,資料庫優化
1.sql的執行順序 from 表名 where 條件 執行順序是從後往前,where條件後面的語句盡可能縮短where 資料執行的範圍。先group by 後order by select 查詢 2.避免過多的聯查,設計合理的表關係 3.遵守常見sql規範,盡可能減少 4.如果表字段過多,經常展示...
sql優化 資料庫優化
資料庫優化 資料庫優化吧我覺應該從硬碟 記憶體和網路頻寬考慮,提高硬碟的讀寫速度,增大頻寬提高吞吐量,增大伺服器記憶體,可以採用讀寫分離,降低單台資料庫的訪問壓力,查詢的時候控制資料量的大小,返回更少資料,減少互動次數,減少cpu及記憶體的開銷,sql優化 如果乙個表中資料量過大我們可以採用橫切割,...
資料庫優化 SQL優化
前面一篇文章從例項的角度進行資料庫優化,通過配置一些引數讓資料庫效能達到最優。但是一些 不好 的sql也會導致資料庫查詢變慢,影響業務流程。本文從sql角度進行資料庫優化,提公升sql執行效率。判斷sql是否有問題時可以通過兩個表象進行判斷 可以使用sar命令,top命令檢視當前系統狀態。也可以通過...