sql長整型 SQL 效能優化梳理

2021-10-11 23:15:27 字數 2217 閱讀 7114

補充內容

3e4先簡單梳理下mysql的基本概念,然後分建立時和查詢時這兩個階段的優化展開。

資料庫通過鎖機制來解決併發場景-共享鎖(讀鎖)和排他鎖(寫鎖)。讀鎖是不阻塞的,多個客戶端可以在同一時刻讀取同乙個資源。寫鎖是排他的,並且會阻塞其他的讀鎖和寫鎖。簡單提下樂觀鎖和悲觀鎖。

要鎖定資料需要一定的鎖策略來配合。

但是mysql的儲存引擎的真實實現不是簡單的行級鎖,一般都是實現了多版本併發控制(mvcc)。mvcc是行級鎖的變種,多數情況下避免了加鎖操作,開銷更低。mvcc是通過儲存資料的某個時間點快照實現的。

事務保證一組原子性的操作,要麼全部成功,要麼全部失敗。一旦失敗,回滾之前的所有操作。mysql採用自動提交,如果不是顯式的開啟乙個事務,則每個查詢都作為乙個事務。

隔離級別控制了乙個事務中的修改,哪些在事務內和事務間是可見的。四種常見的隔離級別:

innodb引擎,最重要,使用最廣泛的儲存引擎。被用來設計處理大量短期事務,具有高效能和自動崩潰恢復的特性。

myisam引擎,不支援事務和行級鎖,崩潰後無法安全恢復。

整數

tinyint,smallint,mediumint,int,bigint 使用的儲存8,16,24,32,64位儲存空間。使用unsigned表示不允許負數,可以使正數的上線提高一倍。

實數

字串

時間型別

優化建議點

索引包含乙個或多個列的值。mysql只能高效的利用索引的最左字首列。索引的優勢:

b-tree

使用最多的索引型別。採用b-tree資料結構來儲存資料(每個葉子節點都包含指向下乙個葉子節點的指標,從而方便葉子節點的遍歷)。b-tree索引適用於全鍵值,鍵值範圍,鍵字首查詢,支援排序。

b-tree索引限制:

雜湊索引

只有精確匹配索引的所有列,查詢才有效。儲存引擎會對所有的索引列計算乙個雜湊碼,雜湊索引將所有的雜湊碼儲存在索引中,並儲存指向每個資料行的指標。

雜湊索引限制:

優化建議點

select id, name, agewhere student s1inner join ( select     id from     student order by     age limit 50,5) as s2 on s1.id = s2.id

來自大神-小寶
1.條件中的字段型別和表結構型別不一致,mysql會自動加轉換函式,導致索引作為函式中的引數失效。

2.like查詢前面部分未輸入,以%開頭無法命中索引。

3.補充2個5.7版本的新特性:

generated column,就是資料庫中這一列由其他列計算而得

create table ******** (sidea double, sideb double, area double as (sidea * sideb / 2));insert into ********(sidea, sideb) values(3, 4);select * from ********;

+-------+-------+------+| sidea | sideb | area |+-------+-------+------+| 3 | 4 | 6 |+-------+-------+------+

支援json格式資料,並提供相關內建函式

create table json_test (name json);insert into json_test values('');select * from json_test where json_contains(name, '$.name1');

來自 jvm 專家 - 達
關注explain在效能分析中的使用

explain select settleid from settle where settleid = "3679"

sql長整型 SQL 效能優化梳理

先簡單梳理下mysql的基本概念,然後分建立時和查詢時這兩個階段的優化展開。1.1 邏輯架構 1.2 鎖 資料庫通過鎖機制來解決併發場景 共享鎖 讀鎖 和排他鎖 寫鎖 讀鎖是不阻塞的,多個客戶端可以在同一時刻讀取同乙個資源。寫鎖是排他的,並且會阻塞其他的讀鎖和寫鎖。簡單提下樂觀鎖和悲觀鎖。要鎖定資料...

SQL效能優化

postgre資料表資料比較多的情況下,使用模糊查詢效能很差,但是使用函式反而快了,返回資料一致,有點不解 warning表2688133條資料,warning message表6954788條資料 這個sql執行老半天都沒反映,耗時169904 ms select count 1 from war...

sql效能優化

任何平台的sql開發者都有自身的困惑,似乎他們一直糾纏在do while迴圈裡,這個迴圈讓他們不斷地重複同樣的錯誤。這是因為資料庫的發展依然不夠成熟。當然,商們也在不斷進步,但是他們還是需要處理更嚴重的問題。併發性,資源管理,空間管理和速度依然制約著sql開發者對開發平台的選擇。我並不期望sql開發...