把Oracle上跑得順滑的SQL原封不動(dòng)扔到SQL Server里結(jié)果慢了十幾倍客戶當(dāng)場質(zhì)疑你是不是換了一臺渣服務(wù)器——這種事我經(jīng)歷過不止一次。換成MySQL表現(xiàn)可能又不一樣。鍋從來不在“機(jī)器性能”而在于每個(gè)數(shù)據(jù)庫引擎各自那套存儲模型、統(tǒng)計(jì)信息、鎖機(jī)制和優(yōu)化器邏輯。本文把主流引擎MySQL InnoDB、SQL Server、Oracle、PostgreSQL的SQL優(yōu)化方案放到同一個(gè)舞臺上拆開講核心目的只有一個(gè)讓你搞清楚同一類SQL在不同引擎里為什么會有截然不同的命運(yùn)以及當(dāng)慢SQL報(bào)出來時(shí)該怎么按引擎對癥下藥。內(nèi)容會涉及索引設(shè)計(jì)、執(zhí)行計(jì)劃、等待事件、深翻頁、去重、窗口函數(shù)、并行度這些高頻場景適合正在做跨數(shù)據(jù)庫開發(fā)的工程師、剛接手?jǐn)?shù)據(jù)庫優(yōu)化任務(wù)的DBA以及那些被“換個(gè)庫就翻車”折磨過的人。1. 為什么同一句SQL在不同引擎里表現(xiàn)天差地別——優(yōu)化思路的起點(diǎn)1.1 存儲模型決定數(shù)據(jù)“怎么被找到”很多人習(xí)慣把“優(yōu)化SQL”當(dāng)成一套萬能公式加索引、避免SELECT *、減少子查詢。這些確實(shí)通用但它們只是戰(zhàn)術(shù)真正決定上限的是數(shù)據(jù)庫底層怎么存數(shù)據(jù)。MySQL InnoDB是典型的聚簇索引表。整張表就是一棵B樹葉子節(jié)點(diǎn)直接放行數(shù)據(jù)。主鍵就是聚簇索引二級索引的葉子節(jié)點(diǎn)存儲的是主鍵值。所以走主鍵查詢等于直接定位走二級索引要先查一遍索引拿到主鍵再回聚簇索引取完整數(shù)據(jù)這就是“回表”。設(shè)計(jì)主鍵時(shí)如果用了UUID之類的隨機(jī)值插入時(shí)會發(fā)生大量頁分裂和日志寫入放大這也是為什么InnoDB從業(yè)務(wù)角度都建議用自增主鍵。SQL Server不一樣。它可以建堆表也可以為表指定聚簇索引。堆表的數(shù)據(jù)頁之間沒有邏輯順序通過IAM頁追蹤聚簇索引表則按聚簇鍵物理排序。在頻繁插入且聚簇鍵變化大的場景堆表反而能減少頁分裂但大多數(shù)生產(chǎn)場景下合理的聚簇索引對范圍查詢幫助極大。這里沒有絕對的“誰更好”只有“你的查詢模式更適合哪種”。Oracle和PostgreSQL都是堆表結(jié)構(gòu)。Oracle通過ROWID直接定位物理行索引葉子節(jié)點(diǎn)存ROWIDPostgreSQL的索引存的是行指針并且靠可見性映射Visibility Map來加速M(fèi)VCC判斷。堆表的回表代價(jià)并不一定比聚簇索引高因?yàn)閿?shù)據(jù)頁可能已經(jīng)在Buffer Pool里。但這也意味著“回表”這件事在每個(gè)引擎里的成本模型是完全不同的。你拿MySQL的經(jīng)驗(yàn)去判斷Oracle的回表開銷從一開始就錯(cuò)了。1.2 優(yōu)化器邏輯與統(tǒng)計(jì)信息的“個(gè)性化差異”SQL優(yōu)化不能只談存儲執(zhí)行計(jì)劃由優(yōu)化器生成而優(yōu)化器吃的是統(tǒng)計(jì)信息。MySQL 8.0的優(yōu)化器比老版本強(qiáng)了不少支持直方圖但整體對復(fù)合索引、OR條件的處理仍然偏保守。經(jīng)典翻車場景一張表兩個(gè)單列索引WHERE a 1 OR b 2MySQL經(jīng)常直接放棄索引合并做全表掃描而Oracle通常能走INDEX合并或BITMAP轉(zhuǎn)換。這跟引擎能力有關(guān)不是你的SQL寫錯(cuò)了。SQL Server的CBO非常成熟尤其是基數(shù)估計(jì)Cardinality Estimation2014年之后的默認(rèn)CE模型對“多列獨(dú)立謂詞”的預(yù)估更接近真實(shí)分布。但它也有自己的坑參數(shù)嗅探。第一次執(zhí)行的參數(shù)值決定了執(zhí)行計(jì)劃后面換個(gè)參數(shù)值可能讓計(jì)劃變得極差。Oracle的CBO是目前最復(fù)雜的優(yōu)化器之一支持自適應(yīng)計(jì)劃、統(tǒng)計(jì)信息自動(dòng)收集但綁定變量窺視、分區(qū)裁剪失效這些老問題仍然存在。PostgreSQL則給用戶留了很大的自定義空間seq_page_cost、random_page_cost這些成本參數(shù)可以直接影響優(yōu)化器選擇。這些差異告訴我們一個(gè)核心道理跨引擎優(yōu)化第一步永遠(yuǎn)是重新評估執(zhí)行計(jì)劃而不是把上一個(gè)庫的“成功經(jīng)驗(yàn)”直接搬過來。1.3 “優(yōu)化”的本質(zhì)不是抄方案而是拆場景我接觸過的很多團(tuán)隊(duì)把SQL優(yōu)化做成了“經(jīng)驗(yàn)搬運(yùn)”MySQL慢就把Oracle那套調(diào)優(yōu)寶典拿來試試不通就怪?jǐn)?shù)據(jù)庫。實(shí)際上一個(gè)SQL慢下來你第一件要做的事不是改語句而是分清楚瓶頸類型IO密集型全表掃描、回表過多、排序落盤、日志寫入慢CPU密集型大量表達(dá)式計(jì)算、嵌套循環(huán)在超大集上運(yùn)行、并行度過高導(dǎo)致爭用鎖/等待密集型鎖塊、鎖升級、死鎖重試、日志同步等待這三個(gè)類型的優(yōu)化手段幾乎不重疊。IO瓶頸看索引和執(zhí)行計(jì)劃CPU瓶頸看表達(dá)式和算子等待瓶頸要看等待事件和并發(fā)配置。接下來幾節(jié)我會把索引、慢SQL定位、實(shí)戰(zhàn)場景和配置陷阱逐一展開。2. 索引設(shè)計(jì)的分水嶺從B樹到列存各引擎的索引脾氣2.1 主鍵與聚簇索引InnoDB的“必選”與SQL Server的“可選”索引設(shè)計(jì)是SQL優(yōu)化里最容易被低估的一環(huán)。很多人以為“建了索引就快了”但索引建錯(cuò)了效果可能比不建還差。MySQL InnoDB里聚簇索引是躲不掉的沒有主鍵時(shí)引擎會挑第一個(gè)非空唯一索引實(shí)在沒有就生成一個(gè)隱藏的rowid列。這意味著你在MySQL里設(shè)計(jì)主鍵本質(zhì)上是在設(shè)計(jì)整張表的物理存儲形態(tài)。隨機(jī)主鍵會導(dǎo)致頁分裂讓插入性能斷崖式下跌過長的主鍵比如字符串型業(yè)務(wù)單號會讓每個(gè)二級索引都變得臃腫因?yàn)槎壦饕~子節(jié)點(diǎn)要存主鍵值。SQL Server給了你選擇權(quán)。堆表和聚簇索引表各有適用場景如果數(shù)據(jù)是流水型追加寫入范圍查詢少、既沒有主鍵的排序需求堆表可能更合適但如果存在大量區(qū)間掃描或需要按特定順序輸出聚簇索引能把隨機(jī)IO變成順序IO。SQL Server還要關(guān)注填充因子Fill Factor和碎片率。索引碎片率超過30%時(shí)即便SQL走對了索引IO也可能高得離譜。運(yùn)維周期性重建索引這件事在MySQL里不常見但在SQL Server里是常規(guī)操作。Oracle和PostgreSQL的主鍵索引只是普通索引不承擔(dān)數(shù)據(jù)存儲職責(zé)。它們的表數(shù)據(jù)按插入順序放在堆里索引負(fù)責(zé)指向行的物理位置。這種架構(gòu)讓“插入”更輕量但也要注意堆表上頻繁更新會使行遷移舊位置留下轉(zhuǎn)發(fā)指針查詢會多一次IO。PostgreSQL的UPDATE會生成新版本行如果表膨脹嚴(yán)重索引掃描會掃描大量死元組導(dǎo)致查詢速度越來越慢——所以autovacuum的配置對PostgreSQL來說不是“可選優(yōu)化”而是“保命設(shè)置”。2.2 覆蓋索引、索引下推與搜索條件寫法索引設(shè)計(jì)的高級玩法是讓索引“覆蓋”查詢避免回表。每個(gè)引擎都支持覆蓋索引但觸發(fā)條件不一樣。MySQL里如果SELECT的字段全部在二級索引中優(yōu)化器會用Index Only ScanExtra列顯示Using index回表完全省掉。SQL Server里叫“覆蓋索引Covering Index”常用INCLUDE語句把不需要參與排序、但需要輸出的列掛到索引葉子上。Oracle支持在索引里額外放一些列即“Include Column”讓索引能覆蓋更多查詢。PostgreSQL同樣支持INCLUDE。還有一種被忽略的能力是索引下推。MySQL的ICPIndex Condition Pushdown會在索引遍歷階段就過濾部分條件減少回表行數(shù)Extra列出現(xiàn)Using index condition就說明下推生效。Oracle對復(fù)合索引的“謂詞推入”也有類似行為但要看執(zhí)行計(jì)劃的Predicate信息。寫SQL時(shí)把條件能寫成區(qū)間就寫成區(qū)間能避免函數(shù)包裹列就避免函數(shù)包裹列。這個(gè)原則四個(gè)引擎都適用但MySQL的感知最強(qiáng)烈因?yàn)樗膬?yōu)化器沒有Oracle那么“會兜底”。2.3 列存索引與分析型查詢另一個(gè)維度的“優(yōu)化”說到索引不能不提SQL Server 2016之后主推的列存儲索引Columnstore。它把同一列的數(shù)據(jù)連續(xù)存放配合批模式執(zhí)行和頁壓縮分析類聚合查詢的IO量可以比行存少一個(gè)數(shù)量級。同樣的思路也是ClickHouse、Spark SQL這類分析引擎提速的核心。從OLTP角度做優(yōu)化時(shí)我們的思維是“減少行的訪問”而分析型場景的思維是“減少列的訪問”。如果你手上有一批報(bào)表SQL在SQL Server里給大表加一個(gè)列存索引通常比瘋狂優(yōu)化SQL寫法有效得多。Oracle也有列存選項(xiàng)Exadata上的Cell多級緩存、In-Memory列式格式MySQL則主要靠第三方引擎補(bǔ)位。這個(gè)例子最能說明“不同數(shù)據(jù)庫引擎優(yōu)化方案”的差異方案不是靠某一條金句總結(jié)出來的而是靠理解引擎各自的強(qiáng)項(xiàng)。3. 慢SQL定位三板斧執(zhí)行計(jì)劃、統(tǒng)計(jì)信息與等待事件3.1 執(zhí)行計(jì)劃怎么看先看實(shí)際行數(shù)與估算行數(shù)的偏差慢SQL排查很多人第一反應(yīng)是看SQL文本試圖“用眼睛優(yōu)化”。但真正專業(yè)的第一動(dòng)作永遠(yuǎn)是拽出執(zhí)行計(jì)劃。四個(gè)引擎看計(jì)劃的方式完全不同你至少要會用自己手上的那個(gè)MySQLEXPLAIN或者EXPLAIN ANALYZE查看實(shí)際執(zhí)行時(shí)間與行數(shù)。重點(diǎn)看typeALL代表全表掃描range代表索引范圍掃描ref代表普通等值匹配、rows預(yù)估值、Extra里的Using filesort、Using temporary。SQL ServerSET STATISTICS IO ON和SET STATISTICS TIME ON可以輸出邏輯讀和耗時(shí)更直觀的是在SSMS里開啟“包含實(shí)際執(zhí)行計(jì)劃”。重點(diǎn)看每個(gè)操作符的Estimated vs Actual Row數(shù)、IO統(tǒng)計(jì)。OracleEXPLAIN PLAN FOR SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR)如果要看實(shí)際行數(shù)需要設(shè)置STATISTICS_LEVELALL然后再執(zhí)行這樣才能看到A-Rows和E-Rows的對比。PostgreSQLEXPLAIN (ANALYZE, BUFFERS)最實(shí)用能同時(shí)看到實(shí)際行數(shù)、啟動(dòng)成本和Buffer讀寫信息。我看執(zhí)行計(jì)劃有一個(gè)固定習(xí)慣先對比操作符的“估算行數(shù)”和“實(shí)際行數(shù)”。如果兩者偏差巨大比如估算1萬行、實(shí)際跑了100萬行那十有八九是統(tǒng)計(jì)信息過期。這時(shí)候再怎么改SQL都是治標(biāo)不治本。3.2 統(tǒng)計(jì)信息過期如何坑掉一條好SQL統(tǒng)計(jì)信息的采集機(jī)制在四個(gè)引擎里各有套路但“過期”帶來的問題都一樣災(zāi)難性。舉個(gè)我排查過的真實(shí)案例一張?jiān)吕塾?jì)訂單表平時(shí)1000萬行月底批量清洗后只剩10萬行。優(yōu)化器不知道表已經(jīng)“瘦身”仍然按1000萬行估算給一個(gè)十幾行的結(jié)果集選了哈希連接加全表掃描接口響應(yīng)從20毫秒暴漲到5秒。引擎的自動(dòng)更新機(jī)制并不總是及時(shí)。MySQL的自動(dòng)統(tǒng)計(jì)更新基于變化行數(shù)超過表大小的閾值指數(shù)級變化時(shí)通常能觸發(fā)但如果你是用大批量DELETE清數(shù)據(jù)后馬上查還是建議手動(dòng)執(zhí)行ANALYZE TABLE。SQL Server的自動(dòng)更新閾值在舊版本里也是基于百分比頻繁小量更新時(shí)統(tǒng)計(jì)信息可能長期滯后定期維護(hù)計(jì)劃里加上UPDATE STATISTICS是DBA的基本功。Oracle的自動(dòng)統(tǒng)計(jì)任務(wù)一般在夜間窗口白天大批量導(dǎo)入數(shù)據(jù)后也需要手動(dòng)DBMS_STATS.GATHER_TABLE_STATS。PostgreSQL的autovacuum在默認(rèn)配置下對大多數(shù)場景夠用但高頻UPDATE的短表仍然容易統(tǒng)計(jì)失真。排查慢SQL時(shí)我建議把“刷新統(tǒng)計(jì)信息”放在前面做掉——成本低、見效快還不會像改SQL那樣引入新風(fēng)險(xiǎn)。做完再重新抓執(zhí)行計(jì)劃往往問題就消失了。3.3 等待事件SQL Server的writelog與Oracle的log file sync有些慢SQL執(zhí)行計(jì)劃完美索引全都用上了但就是快不起來。這時(shí)候要看的不是執(zhí)行計(jì)劃而是時(shí)間花在哪里了。SQL Server里有一個(gè)很常見的等待類型WRITELOG。它表示會話在提交事務(wù)時(shí)需要等待日志記錄被寫入磁盤。凡是高頻小事務(wù)場景——比如循環(huán)逐行INSERT、頻繁UPDATE單行——都能看到大量WRITELOG等待。根因通常是磁盤的fsync延遲太高HDD、共享云盤、日志文件與數(shù)據(jù)文件混用或者日志文件初始化太小導(dǎo)致頻繁自動(dòng)增長。優(yōu)化辦法把事務(wù)日志文件放到低延遲獨(dú)立磁盤、合并小事務(wù)為批量提交、合理預(yù)分配日志文件大小。別小看這個(gè)等待它經(jīng)常是“CPU不忙、磁盤不忙、但接口就是慢”的元兇。Oracle里對應(yīng)的等待是log file sync和log file parallel write背后邏輯高度相似提交事務(wù)時(shí)LGWR進(jìn)程要確保日志緩沖寫入聯(lián)機(jī)日志文件。排查方法比SQL Server稍微復(fù)雜可以從AWR報(bào)告的Top 5 Timed Events入手確認(rèn)Wait Event是不是log file sync再檢查redo log所在磁盤IO能力。MySQL的對應(yīng)參數(shù)是innodb_flush_log_at_trx_commit1時(shí)的每次提交刷盤如果業(yè)務(wù)允許改成2會有數(shù)量級的性能提升但代價(jià)是丟最多1秒的事務(wù)日志。這個(gè)取舍沒有標(biāo)準(zhǔn)答案要看業(yè)務(wù)對數(shù)據(jù)安全的要求。等待事件分析的價(jià)值在于它幫你把“SQL慢”拆成了“SQL自己慢”和“環(huán)境讓它慢”。前者靠索引和執(zhí)行計(jì)劃解決后者靠配置和磁盤布局解決。很多DBA只盯著SQL文本忽略等待類型這是排查慢SQL最容易走的彎路。4. 實(shí)戰(zhàn)拆解去重、分頁、窗口函數(shù)在四大引擎中的優(yōu)化做法4.1 去重DISTINCT、GROUP BY與ROW_NUMBER的代價(jià)差異“去重”是搜索引擎里最常見的SQL需求但不同引擎對去重的執(zhí)行方式完全不同。很多人以為DISTINCT就是簡單的“選不同”實(shí)際它的代價(jià)往往被嚴(yán)重低估。DISTINCT在四個(gè)引擎里核心執(zhí)行方式無非兩種哈希去重或排序去重。沒有索引時(shí)MySQL可能使用臨時(shí)表SQL Server可能走Sort算子并觸發(fā)tempdb溢出Oracle默認(rèn)傾向HASH UNIQUEPostgreSQL在work_mem不足時(shí)會把HashAgg退化成SortGroupAggregate。實(shí)操中我遇到過最坑的寫法是先JOIN再DISTINCT。用訂單表和訂單明細(xì)表關(guān)聯(lián)最終結(jié)果希望得到“有哪些客戶下單”第一版SQL往往寫成SELECT DISTINCT c.customer_id ... FROM customers c JOIN orders o ON ...。這種寫法會把明細(xì)表放大后才去重中間結(jié)果驚人。正確的做法是改成EXISTS子查詢SELECT customer_id FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id c.customer_id)。執(zhí)行計(jì)劃直接從HASH JOIN變成SEMI JOIN行數(shù)少了一個(gè)量級。不同去重手段的選擇也要看業(yè)務(wù)語義需求推薦方式原因簡單取唯一值SELECT DISTINCT col引擎有專門算子寫法直觀按某字段分組取其他字段GROUP BY 聚合函數(shù)不依賴窗口函數(shù)執(zhí)行計(jì)劃更清晰每組內(nèi)取最新一條/前N條ROW_NUMBER() OVER(PARTITION BY ... ORDER BY ...)窗口函數(shù)語義最強(qiáng)SQL Server 2012/MySQL 8.0/Oracle/PostgreSQL均支持注意一個(gè)細(xì)節(jié)DISTINCT對NULL的處理是“去重后只保留一個(gè)NULL”GROUP BY會把NULL當(dāng)成一個(gè)分組常規(guī)業(yè)務(wù)上兩者等價(jià)但如果你寫的是多列去重務(wù)必確認(rèn)NULL列的處理是否符合預(yù)期這一塊容易出隱蔽的語義Bug。4.2 深翻頁OFFSET不慢慢的是丟棄分頁是所有業(yè)務(wù)系統(tǒng)躲不開的SQL場景。淺分頁沒壓力深翻頁才是真正的性能殺手。四個(gè)引擎都支持LIMIT/OFFSET或等價(jià)語法但原理一樣先掃描出從第1行到第(offsetlimit)行的全部數(shù)據(jù)丟棄前面的offset行返回最后limit行。頁數(shù)越深掃描和丟棄的行越多。MySQL的經(jīng)典寫法是LIMIT 1000000, 20它會掃到第100萬行再丟掉SQL Server用OFFSET 1000000 ROWS FETCH NEXT 20 ROWS ONLY底層也是排序后跳過Oracle老版本用ROWNUM嵌套子查詢12c以后有FETCH FIRST但深分頁的本質(zhì)沒有變化。PostgreSQL的LIMIT/OFFSET同樣避免不了這個(gè)問題。解決深翻頁最有效的方案是Keyset Pagination也叫游標(biāo)分頁。不用OFFSET而是帶一個(gè)排序鍵的WHERE條件-- 傳統(tǒng)深翻頁慢 SELECT * FROM orders ORDER BY id OFFSET 1000000 ROWS FETCH NEXT 20 ROWS ONLY; -- Keyset Pagination快 SELECT * FROM orders WHERE id 1000000 ORDER BY id FETCH FIRST 20 ROWS ONLY;Keyset方式的執(zhí)行計(jì)劃是典型的索引范圍掃描理論上可以做到翻到第N頁都只有20行的開銷。前提是排序鍵絕對唯一且穩(wěn)定。如果業(yè)務(wù)排序需要多字段比如ORDER BY created_at DESC, id DESCWHERE條件也要按同樣順序帶上游標(biāo)值。字符串排序、日期排序同樣適用。實(shí)測數(shù)據(jù)最直觀一張200萬行訂單表傳統(tǒng)OFFSET翻到第1000頁每頁20行耗時(shí)約為280毫秒改為Keyset后穩(wěn)定在0.5毫秒左右。所以如果你正在負(fù)責(zé)一個(gè)有深翻頁需求的接口建議趁早改造不要等用戶報(bào)告“越翻越慢”。4.3 窗口函數(shù)與并行分析需求在不同引擎里的落地姿勢窗口函數(shù)是SQL優(yōu)化工具箱里的高頻武器。SQL Server從2012版本開始支持ROW_NUMBER、RANK、DENSE_RANK、SUM() OVER()等再早只能靠自連接實(shí)現(xiàn)MySQL從8.0才開始支持之前只能用變量模擬Oracle和PostgreSQL自帶完整的窗口函數(shù)支持它們的執(zhí)行器對這一類算子優(yōu)化也更成熟。舉一個(gè)十分常見的例子“查每個(gè)客戶最近一筆訂單”。用窗口函數(shù)可以寫成SELECT customer_id, order_id, order_date FROM ( SELECT customer_id, order_id, order_date, ROW_NUMBER() OVER(PARTITION BY customer_id ORDER BY order_date DESC) AS rn FROM orders ) t WHERE rn 1;這段SQL在四個(gè)引擎里都能跑但注意如果orders表非常大窗口函數(shù)的PARTITION BYORDER BY需要一次全局排序。優(yōu)化點(diǎn)是建立復(fù)合索引(customer_id, order_date DESC)讓窗口排序直接走索引有序掃描避免顯式排序。MySQL 8.0對索引有序性的依賴最強(qiáng)索引建立不對時(shí)執(zhí)行計(jì)劃會出現(xiàn)Using filesort數(shù)據(jù)量大時(shí)性能差距能達(dá)幾十倍。SQL Server則可能更依賴內(nèi)存里的Sort算子配合列存索引時(shí)有時(shí)能獲得更激進(jìn)的批處理加速。再說并行SQL優(yōu)化。Oracle的并行DML、并行查詢能力很強(qiáng)可以在SQL上加PARALLEL Hint讓一個(gè)復(fù)雜聚合查詢同時(shí)跑多個(gè)并行服務(wù)進(jìn)程SQL Server用MAXDOP設(shè)置并行度PostgreSQL從9.6開始引入了并行順序掃描和并行聚合但并行度受限于planning參數(shù)。MySQL至今沒有原生的“一條SQL自動(dòng)并行”能力一個(gè)高成本查詢只能單線程執(zhí)行。這個(gè)差異意味著同樣的分析SQL在Oracle和PG上可以通過調(diào)整并行度實(shí)現(xiàn)質(zhì)的飛躍在MySQL上則必須靠優(yōu)化語句本身、建物化視圖或引入分析引擎來解決問題?？缫鎯?yōu)化時(shí)必須先認(rèn)清有些特性是這個(gè)引擎天生沒有的與其死磕不如改變架構(gòu)方案。5. 常見陷阱與規(guī)避從SQL寫法到引擎配置的教訓(xùn)5.1 參數(shù)化與SQL注入安全底線也是性能底線搜索引擎熱詞榜里永遠(yuǎn)有SQL注入這不是偶然。很多運(yùn)維和開發(fā)把“SQL注入防護(hù)”當(dāng)成純安全議題實(shí)際上它與SQL優(yōu)化是同一件事。參數(shù)化查詢Prepared Statement除了能防注入還能提升執(zhí)行計(jì)劃復(fù)用率。以SQL Server為例如果業(yè)務(wù)代碼每次都拼接一個(gè)新的SQL文本提交每次都需要硬解析生成新的執(zhí)行計(jì)劃CPU壓力升高、計(jì)劃緩存命中率下降改成參數(shù)化寫法后同一個(gè)計(jì)劃模板可以被反復(fù)復(fù)用。Oracle的綁定變量、MySQL的PREPARE、PostgreSQL的PREPARE也都是一樣的邏輯。反過來說SQL注入的根因就是非參數(shù)化的字符串拼接?；ヂ?lián)網(wǎng)上流傳的所謂“繞過手法”本質(zhì)上都是利用拼接邏輯的缺陷做字符串逃逸。修復(fù)方式?jīng)]有捷徑全部改成參數(shù)化查詢數(shù)據(jù)庫賬號按庫表權(quán)限最小化應(yīng)用層再做一層白名單校驗(yàn)。參數(shù)化一上注入漏洞攻擊面立刻歸零計(jì)劃緩存利用率同步提升——一次改造安全性和性能雙收益。5.2 隱式轉(zhuǎn)換與函數(shù)包裹讓索引瞬間失效的寫法這是跨引擎優(yōu)化里最統(tǒng)一的一條經(jīng)驗(yàn)在索引列上做函數(shù)運(yùn)算或隱式類型轉(zhuǎn)換絕大多數(shù)情況下會讓索引失效。MySQL里最常見的翻車現(xiàn)場是字段類型是VARCHARSQL寫成了WHERE phone 13800138000MySQL會先把字段轉(zhuǎn)成數(shù)值再比較索引直接報(bào)廢。解決辦法就是讓參數(shù)類型與字段類型保持一致寫成13800138000字符串。SQL Server也有類似行為字符列與數(shù)值常量比較時(shí)常會觸發(fā)隱式轉(zhuǎn)換執(zhí)行計(jì)劃里會出現(xiàn)CONVERT_IMPLICIT掃描行數(shù)瞬間暴增。日期函數(shù)包裹列是另一個(gè)通病。WHERE DATE(create_time) 2024-01-01這種寫法會把create_time列塞進(jìn)函數(shù)里即便該列有索引也掃不了。改成WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00既能走索引邏輯上也等價(jià)。引擎差異在這里也有體現(xiàn)。Oracle里你還能用函數(shù)索引如TO_CHAR(create_time, YYYY-MM-DD)建索引兜底MySQL 8.0也支持函數(shù)索引SQL Server可以通過計(jì)算列加索引實(shí)現(xiàn)類似效果。但我的習(xí)慣仍然是優(yōu)先改SQL寫法而不是為不合理的寫法建特殊索引。因?yàn)楹瘮?shù)索引對寫入有額外維護(hù)成本而且應(yīng)用一旦換寫法索引就浪費(fèi)了。5.3 系統(tǒng)性“偽慢SQL”監(jiān)聽、連接池與臨時(shí)文件最后一類慢SQL其實(shí)SQL本身是無辜的。比如Oracle報(bào)錯(cuò)ORA-12518“監(jiān)聽程序無法分發(fā)”這個(gè)錯(cuò)誤的本質(zhì)往往不是SQL性能問題而是監(jiān)聽進(jìn)程無法fork新的服務(wù)器進(jìn)程——常見原因是processes參數(shù)打滿、操作系統(tǒng)進(jìn)程數(shù)限制、SGA/PGA內(nèi)存不足。排查方向是調(diào)大processes、sessions參數(shù)限制應(yīng)用的空閑連接數(shù)檢查系統(tǒng)內(nèi)存。如果你只盯著SQL調(diào)優(yōu)永遠(yuǎn)看不到問題。連接池配置同理。很多接口慢不是SQL慢而是連接池里線程都在排隊(duì)等連接。HikariCP、Druid這類連接池的maximumPoolSize設(shè)置過小高并發(fā)時(shí)請求全部阻塞在獲取連接階段設(shè)置過大數(shù)據(jù)庫端又會資源爭用。我在實(shí)際優(yōu)化項(xiàng)目里見過接口P99從800毫秒降到80毫秒的案例改動(dòng)僅僅是調(diào)整連接池大小和空閑超時(shí)SQL一行沒改。臨時(shí)文件和日志文件也經(jīng)常被忽視。SQL Server的tempdb如果默認(rèn)配置且與其他庫共用硬盤排序和哈希連接一旦落盤就會拖慢所有查詢MySQL的tmp_table_size過小時(shí)GROUP BY會轉(zhuǎn)到磁盤臨時(shí)表PostgreSQL的work_mem直接決定Sort/Hash操作是走內(nèi)存還是走磁盤默認(rèn)4MB對一個(gè)稍大排序來說小得離譜。所以當(dāng)你面對一條“查了半小時(shí)還不出來”的SQL排查順序我建議是統(tǒng)計(jì)信息→等待事件→執(zhí)行計(jì)劃→SQL改寫→索引調(diào)整→系統(tǒng)配置。前面幾步可以快速排除環(huán)境因素后面幾步才是真正的SQL優(yōu)化。順序反了很容易在一個(gè)錯(cuò)誤的方向上耗費(fèi)半天。做數(shù)據(jù)庫優(yōu)化這些年我最深的體會是優(yōu)化不是背答案而是理解每個(gè)引擎是怎么存、怎么找、怎么鎖的。同一套經(jīng)驗(yàn)換一個(gè)數(shù)據(jù)庫往往就失真所以每次跨庫排查我都默認(rèn)自己是個(gè)新手從頭看執(zhí)行計(jì)劃和等待事件。很多團(tuán)隊(duì)迷信所謂的“大廠調(diào)優(yōu)參數(shù)”拿一套配置到處套結(jié)果連基礎(chǔ)的數(shù)據(jù)文件布局都沒看。老老實(shí)實(shí)按“統(tǒng)計(jì)信息是否新鮮、等待事件是否異常、執(zhí)行計(jì)劃是否合理、索引是否被有效使用”這個(gè)順序走一遍多數(shù)慢SQL問題都能在半小時(shí)內(nèi)定位。最后再分享一個(gè)實(shí)戰(zhàn)習(xí)慣每次只改一個(gè)變量。改完SQL跑一次驗(yàn)證建完索引再看一遍執(zhí)行計(jì)劃。多個(gè)優(yōu)化點(diǎn)一起上出了問題你根本不知道是誰的鍋。