MySQL安魂九霄，PostgreSQL駛向云外
當(dāng)前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
本月 MySQL 9.0 終于發(fā)布了，距離上一次大版本更新 8.0 (@2016-09) 已經(jīng)過去整整八年。然而這個空洞無物的所謂 “創(chuàng)新版本” 卻猶如一個惡劣的玩笑，宣告著 MySQL 正在死去。 空洞無物的創(chuàng)新版本 糊弄了事的向量類型 姍姍來遲的JS函數(shù) 日漸落后的功能特性 越新越差的性能表現(xiàn) 無可救藥的隔離等級 枯萎收縮的生態(tài)規(guī)模 是誰殺死了MySQL？ PG駛向云外，MySQL安魂九霄 PostgreSQL 正在高歌猛進(jìn)，而 MySQL 卻日薄西山，作為 MySQL 生態(tài)主要抗旗者的 Percona 也不得不悲痛地承認(rèn)這一現(xiàn)實，連發(fā)了三篇《MySQL將何去何從》，《Oracle最終還是殺死了MySQL》，《Oracle還能挽救MySQL嗎》，公開表達(dá)了對 MySQL 的失望與沮喪； Percona 的 CEO Peter Zaitsev 也直言不諱道：
有的數(shù)據(jù)庫正在吞噬數(shù)據(jù)庫世界，而有的數(shù)據(jù)庫正在黯然地凋零死去。 MySQL is dead，Long live PostgreSQL！ 空洞無物的創(chuàng)新版本MySQL 官網(wǎng)發(fā)布的 "What's New in MySQL 9.0"[5] 介紹了 9.0 版本引入的幾個新特性，而 MySQL 9.0 新功能概覽 一文對此做了扼要的總結(jié)：
然后呢？就這些嗎？這就沒了！？ 這確實是讓人驚詫不已，因為 PostgreSQL 每年的大版本發(fā)布都有無數(shù)的新功能特性，例如計劃今秋發(fā)布的 PostgreSQL 17 還只是 beta1，就已然有著蔚為壯觀的新增特性列表：
而最近幾年的 PostgreSQL 新增特性甚至足夠?qū)ｉT編成一本書了。比如《快速掌握PostgreSQL版本新特性》便收錄了 PostgreSQL 最近七年的重要新特性 —— 將目錄塞的滿滿當(dāng)當(dāng)：
回頭再來看看 MySQL 9 更新的六個特性，后四個都屬于無關(guān)痛癢，一筆帶過的小修補，拿出來講都嫌丟人。而前兩個 向量數(shù)據(jù)類型 和 JS存儲過程 才算是重磅亮點。 BUT —— MySQL 9.0 的向量數(shù)據(jù)類型只是 BLOB 類型換皮 —— 只加了個數(shù)組長度函數(shù)，而這種程度的功能，28年前 PostgreSQL 誕生的時候就支持了。 而 Javascript 存儲過程支持竟然還是一個 企業(yè)版獨占特性，開源版不提供 —— 同樣的功能，13年前 的 PostgreSQL 9.1 就已經(jīng)有了。 時隔八年的 “創(chuàng)新大版本” 更新就帶來了倆 “老特性”，其中一個還是企業(yè)版特供。“創(chuàng)新”這倆字，在這里顯得如此辣眼與諷刺。 糊弄了事的向量類型2023年，AI爆火，帶動了向量數(shù)據(jù)庫賽道。當(dāng)下幾乎所有主流 DBMS 都已經(jīng)提供向量數(shù)據(jù)類型支持 —— MySQL 除外。 用戶可能原本期待著在 9.0 創(chuàng)新版，向量支持能彌補一些缺憾，結(jié)果發(fā)布后等到的只有震撼 —— 竟然還可以這么糊弄？ 在 MySQL 9.0 的 官方文檔[6] 上，只有三個關(guān)于向量類型的函數(shù)。拋開與字符串互轉(zhuǎn)的兩個，真正的功能函數(shù)就一個
向量數(shù)據(jù)庫的門檻不是一般的低 —— 有個向量距離度量函數(shù)就行（內(nèi)積，10行C代碼，小學(xué)生水平編程任務(wù)），這樣可以通過全表掃描求距離 + 但 MySQL 9 甚至連這樣一個最基本的向量距離函數(shù)都懶得去實現(xiàn)，這絕對不是能力問題，而是 Oracle 根本就不想好好做 MySQL 了。老司機(jī)一眼就能看出這里的所謂 “向量類型” 不過是 不糊弄的例子可以參考 MySQL 的老對手 PostgreSQL。在過去一年中，PG 生態(tài)里就涌現(xiàn)出了至少六款向量數(shù)據(jù)庫擴(kuò)展（
在這一年內(nèi)， 拿 向量是新的JSON[10]，然而向量數(shù)據(jù)庫的宴席都已經(jīng)散場了，MySQL 都還沒來得及上桌 —— 它完美錯過了下一個十年 AI 時代的增長動能，正如它在上一個十年里錯過互聯(lián)網(wǎng)時代的JSON文檔數(shù)據(jù)庫一樣。 姍姍來遲的JS函數(shù)另一個 MySQL 9.0 帶來的 “重磅” 特性是 —— Javascript 存儲過程。 然而用 Javascript 寫存儲過程并不是什么新鮮事 —— 早在 2011 年，PostgreSQL 9.1 就已經(jīng)可以通過 如果我們查看 DB-Engine 近十二年的 “數(shù)據(jù)庫熱度趨勢” ，不難發(fā)現(xiàn)只有 PostgreSQL 與 Mongo 兩款 DBMS 在獨領(lǐng)風(fēng)騷 —— MongoDB (2009) 與 PostgreSQL 9.2 (2012) 都極為敏銳地把握住了互聯(lián)網(wǎng)開發(fā)者的需求 —— 在 “JSON崛起” 的第一時間就添加 JSON 特性支持（文檔數(shù)據(jù)庫），從而在過去十年間吃下了數(shù)據(jù)庫領(lǐng)域最大的增長紅利。
當(dāng)然，MySQL 的干爹 —— Oracle 也在2014年底的12.1中添加了 JSON 特性與 Javascript 存儲過程的支持 —— 而 MySQL 自己則不幸地等到了 2024 年才補上這一課 —— 但已經(jīng)太遲了！ Oracle 支持用 C，SQL，PL/SQL，Pyhton，Java，Javascript 編寫存儲過程。但在 PostgreSQL 支持的二十多種存儲過程語言面前，只能說也是小巫見大巫，只能甘拜下風(fēng)了：
不同于 PostgreSQL 與 Oracle 的開發(fā)理念，MySQL 的各種最佳實踐里都不推薦使用存儲過程 —— 所以 Javascript 函數(shù)對于 MySQL 來說是個雞肋特性。然而即便如此，Oracle 還是把 Javascript 存儲過程支持做成了一個 MySQL企業(yè)版專屬 的特性 —— 考慮到絕大多數(shù) MySQL 用戶使用的都是開源社區(qū)版本，這個特性屬實是發(fā)布了個寂寞。 日漸落后的功能特性MySQL 在功能上缺失的絕不僅僅是是編程語言/存儲過程支持，在各個功能維度上，MySQL 都落后它的競爭對手 PostgreSQL 太多了 —— 功能落后不僅僅是在數(shù)據(jù)庫內(nèi)核功能上，更發(fā)生在擴(kuò)展生態(tài)維度。 來自 CMU 的 Abigale Kim 對主流數(shù)據(jù)庫的可擴(kuò)展性[14]進(jìn)行了研究：PostgreSQL 有著所有 DBMS 中最好的 可擴(kuò)展性（Extensibility），以及其他數(shù)據(jù)庫生態(tài)難望其項背的擴(kuò)展插件數(shù)量 —— 375+，這還只是 PGXN 注冊在案的實用插件，實際生態(tài)擴(kuò)展總數(shù)已經(jīng)破千[15]。
這些擴(kuò)展插件為 PostgreSQL 提供了各種各樣的功能 —— 地理空間，時間序列，向量檢索，機(jī)器學(xué)習(xí)，OLAP分析，全文檢索，圖數(shù)據(jù)庫，讓 PostgreSQL 真正成為一專多長的全棧數(shù)據(jù)庫 —— 單一數(shù)據(jù)庫選型便可替代各式各樣的專用組件：MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是專用分析數(shù)倉與數(shù)據(jù)湖。
當(dāng) MySQL 還落在 “關(guān)系型 OLTP 數(shù)據(jù)庫” 的窠臼時， PostgreSQL 早已經(jīng)放飛自我，從一個關(guān)系型數(shù)據(jù)庫發(fā)展成了一個多模態(tài)的數(shù)據(jù)庫，最終成為了一個數(shù)據(jù)管理的抽象框架與開發(fā)平臺。 PostgreSQL正在吞噬數(shù)據(jù)庫世界[16] —— 它正在通過插件的方式，將整個數(shù)據(jù)庫世界內(nèi)化其中。“一切皆用 Postgres[17]” 也已經(jīng)不再是少數(shù)精英團(tuán)隊的前沿探索，而是成為了一種進(jìn)入主流視野的最佳實踐。 而在新功能支持上，MySQL 卻顯得十分消極 —— 一個應(yīng)該有大量 Breaking Change 的“創(chuàng)新大版本更新”，不是糊弄人的擺爛特性，就是企業(yè)級的特供雞肋，一個大版本就連雞零狗碎的小修小補都湊不夠數(shù)。 越新越差的性能表現(xiàn)缺少功能也許并不是一個無法克服的問題 —— 對于一個數(shù)據(jù)庫來說，只要它能將自己的本職工作做得足夠出彩，那么架構(gòu)師與DBA總是可以多費些神，用各種其他的數(shù)據(jù)積木一起拼湊出所需的功能。 MySQL 曾引以為傲的核心特點便是 性能 —— 至少對于互聯(lián)網(wǎng)場景下的簡單 OLTP CURD 來說，它的性能是非常不錯的。然而不幸地是，這一點也正在遭受挑戰(zhàn)：Percona 的博文《Sakila：你將何去何從[18]》中提出了一個令人震驚的結(jié)論： MySQL 的版本越新，性能反而越差
根據(jù) Percona 的測試，在 sysbench 與 TPC-C 測試下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出現(xiàn)了平均高達(dá) 20% 的下降。而 MySQL 專家 Mark Callaghan 進(jìn)一步進(jìn)行了 詳細(xì)的性能回歸測試[19]，確認(rèn)了這一現(xiàn)象：
盡管 MySQL 的優(yōu)化器在 8.x 有一些改進(jìn)，一些復(fù)雜查詢場景下的性能有所改善，但分析與復(fù)雜查詢本來就不是 MySQL 的長處與適用場景，只能說聊勝于無。相反，如果作為基本盤的 OLTP CRUD 性能出了這么大的折損，那確實是完全說不過去的。
Peter Zaitsev 在博文《Oracle最終還是殺死了MySQL[20]》中評論：“與 MySQL 5.6 相比，MySQL 8.x 單線程簡單工作負(fù)載上的性能出現(xiàn)了大幅下滑。你可能會說增加功能難免會以犧牲性能為代價，但 MariaDB 的性能退化要輕微得多，而 PostgreSQL 甚至能在 新增功能的同時顯著提升性能·[21]”。
MySQL的性能隨版本更新而逐步衰減，但在同樣的性能回歸測試中，PostgreSQL 性能卻可以隨版本更新有著穩(wěn)步提升。特別是在最關(guān)鍵的寫入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。 在 Mark Callaghan 的 性能橫向?qū)Ρ?/span>[22] （sysbench 吞吐場景） 中，我們可以看到五年前 PG 11 與 MySQL 5.6 的性能比值（藍(lán)），與當(dāng)下 PG 16 與 MySQL 8.0.34 的性能比值（紅）。PostgreSQL 和 MySQL 的性能差距在這五年間拉的越來越大。
幾年前的業(yè)界共識是 PostgreSQL 與 MySQL 在 簡單 OLTP CRUD 場景 下的性能基本相同。然而此消彼長之下，現(xiàn)在 PostgreSQL 的性能已經(jīng)遠(yuǎn)遠(yuǎn)甩開 MySQL 了。PostgreSQL 的各種讀吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些寫入場景下的吞吐量更是達(dá)到了 200% 甚至 500% 的恐怖水平。 MySQL 賴以安身立命的性能優(yōu)勢，已經(jīng)不復(fù)存在了。 無可救藥的隔離等級如果只是性能不好，總歸還有辦法來優(yōu)化修補。但如果是正確性出了問題，那真就是無可救藥了。 《MySQL正確性竟如此拉垮？[23]》一文指出，在正確性這個體面數(shù)據(jù)庫產(chǎn)品必須的基本屬性上，MySQL 的表現(xiàn)一塌糊涂。 權(quán)威的分布式事務(wù)測試組織 JEPSEN[24] 研究發(fā)現(xiàn)，MySQL 文檔聲稱實現(xiàn)的 可重復(fù)讀/RR 隔離等級，實際提供的正確性保證要弱得多 —— MySQL 8.0.34 默認(rèn)使用的 RR 隔離等級實際上并不可重復(fù)讀，甚至既不原子也不單調(diào)，連 單調(diào)原子視圖/MAV 的基本水平都不滿足。
MySQL 的 ACID 存在缺陷，且與文檔承諾不符 —— 而輕信這一虛假承諾可能會導(dǎo)致嚴(yán)重的正確性問題，例如數(shù)據(jù)錯漏與對賬不平。對于一些數(shù)據(jù)完整性很關(guān)鍵的場景 —— 例如金融，這一點是無法容忍的。 此外，能“避免”這些異常的 MySQL 可串行化/SR 隔離等級難以生產(chǎn)實用，也非官方文檔與社區(qū)認(rèn)可的最佳實踐；盡管專家開發(fā)者可以通過在查詢中顯式加鎖來規(guī)避此類問題，但這樣的行為極其影響性能，而且容易出現(xiàn)死鎖。 與此同時，PostgreSQL 在 9.1 引入的 可串行化快照隔離（SSI） 算法可以用極小的性能代價提供完整可串行化隔離等級 —— 而且 PostgreSQL 的 SR 在正確性實現(xiàn)上毫無瑕疵 —— 這一點即使是 Oracle 也難以企及。
李海翔教授在《一致性八仙圖》論文中，系統(tǒng)性地評估了主流 DBMS 隔離等級的正確性，圖中藍(lán)/綠色代表正確用規(guī)則/回滾避免異常；黃A代表異常，越多則正確性問題就越多；紅“D”指使用了影響性能的死鎖檢測來處理異常，紅D越多性能問題就越嚴(yán)重； 不難看出，這里正確性最好（無黃A）的實現(xiàn)是 PostgreSQL SR，與基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通過機(jī)制與規(guī)則避免并發(fā)異常；而 MySQL 出現(xiàn)了大面積的黃A與紅D，正確性水平與實現(xiàn)手法糙地不忍直視。 做正確的事很重要，而正確性是不應(yīng)該拿來做利弊權(quán)衡的。在這一點上，開源關(guān)系型數(shù)據(jù)庫兩巨頭 MySQL 和 PostgreSQL 在早期實現(xiàn)上就選擇了兩條截然相反的道路：MySQL 追求性能而犧牲正確性；而學(xué)院派的 PostgreSQL 追求正確性而犧牲了性能。 在互聯(lián)網(wǎng)風(fēng)口上半場中，MySQL 因為性能優(yōu)勢占據(jù)先機(jī)乘風(fēng)而起。但當(dāng)性能不再是核心考量時，正確性就成為了 MySQL 的 致命出血點。更為可悲的是，MySQL 連犧牲正確性換來的性能，都已經(jīng)不再占優(yōu)了，這著實讓人唏噓不已。 枯萎收縮的生態(tài)規(guī)模對一項技術(shù)而言，用戶的規(guī)模直接決定了生態(tài)的繁榮程度。瘦死的駱駝比馬大，爛船也有三斤釘。MySQL 曾經(jīng)搭乘互聯(lián)網(wǎng)東風(fēng)扶搖而起，攢下了豐厚的家底，它的 Slogan 就很能說明問題 —— “世界上最流行的開源關(guān)系型數(shù)據(jù)庫”。
不幸的是在 2023 年，至少根據(jù)全世界最權(quán)威的開發(fā)者調(diào)研之一的 StackOverflow Annual Developer Survey[25] 結(jié)果來看，MySQL 的使用率已經(jīng)被 PostgreSQL 反超了 —— 最流行數(shù)據(jù)庫的桂冠已經(jīng)被 PostgreSQL 摘取。 特別是，如果將過去七年的調(diào)研數(shù)據(jù)放在一起，就可以得到這幅 PostgreSQL / MySQL 在專業(yè)開發(fā)者中使用率的變化趨勢圖（左上） —— 在橫向科比的同一標(biāo)準(zhǔn)下，PostgreSQL 流行與 MySQL 那魘葡緣靡荒苛巳弧�
對于中國來說，此消彼長的變化趨勢也同樣成立。但如果對中國開發(fā)者說 PostgreSQL 比 MySQL 更流行，那確實是違反直覺與事實的。 將 StackOverflow 專業(yè)開發(fā)者按照國家細(xì)分，不難看出在主要國家中（樣本數(shù) > 600 的 31 個國家），中國的 MySQL 使用率是最高的 —— 58.2% ，而 PG 的使用率則是最低的 —— 僅為 27.6%，MySQL 用戶幾乎是 PG 用戶的一倍。 與之恰好反過來的另一個極端是真正遭受國際制裁的俄聯(lián)邦：由開源社區(qū)運營，不受單一主體公司控制的 PostgreSQL 成為了俄羅斯的數(shù)據(jù)庫大救星 —— 其 PG 使用率以 60.5% 高居榜首，是其 MySQL 使用率 27% 的兩倍。
中國因為同樣的自主可控信創(chuàng)邏輯，最近幾年 PostgreSQL 的使用率也出現(xiàn)了顯著躍升 —— PG 的使用率翻了三倍，而 PG 與 MySQL 用戶比例已經(jīng)從六七年前的 5:1 ，到三年前的3:1，再迅速發(fā)展到現(xiàn)在的 2:1，相信會在未來幾年內(nèi)會很快追平并反超世界平均水平。畢竟，有這么多的國產(chǎn)數(shù)據(jù)庫，都是基于 PostgreSQL 打造而成 —— 如果你做政企信創(chuàng)軟件生意，那么大概率已經(jīng)在用 PostgreSQL 了。 拋開政治因素，用戶選擇使用一款數(shù)據(jù)庫與否，核心考量還是質(zhì)量、安全、效率、成本等各個方面是否“先進(jìn)”。先進(jìn)的因會反映為流行的果，流行的東西因為落后而過氣，而先進(jìn)的東西會因為先進(jìn)變得流行，沒有“先進(jìn)”打底，再“流行”也難以長久。號稱“最流行”的 MySQL，終究還是難敵時間的審判。 究竟是誰殺死了MySQL？MySQL 曾經(jīng)也輝煌過，但再精彩的演出也會落幕。 MySQL 正在死去 —— 更新疲軟，功能落后，性能劣化，質(zhì)量出血，生態(tài)萎縮，此乃天命，實非人力所能救也。但究竟是誰殺死了 MySQL，難道是 PostgreSQL 嗎？Peter Zaitsev 在《Oracle最終還是殺死了MySQL》一文中控訴，Oracle 的不作為與瞎指揮最終害死了 MySQL；并在后續(xù)《Oracle還能挽救MySQL嗎》一文中指出了真正的根因： MySQL 的知識產(chǎn)權(quán)被 Oracle 所擁有，它不是像 PostgreSQL 那種 “由社區(qū)擁有和管理” 的數(shù)據(jù)庫，也沒有 PostgreSQL 那樣廣泛的獨立公司貢獻(xiàn)者。不論是 MySQL 還是其分叉 MariaDB，它們都不是真正意義上像 Linux，PostgreSQL，Kubernetes 這樣由社區(qū)驅(qū)動的的原教旨純血開源項目，而是由單一商業(yè)公司主導(dǎo)。 比起向一個商業(yè)競爭對手貢獻(xiàn)代碼，白嫖競爭對手的代碼也許是更為明智的選擇 —— AWS 和其他云廠商利用 MySQL 內(nèi)核參與數(shù)據(jù)庫領(lǐng)域的競爭，卻不回饋任何貢獻(xiàn)。于是作為競爭對手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也參與進(jìn)來搞云 —— 僅僅只關(guān)注它自己的 MySQL heatwave 云版本，就像 AWS 僅僅專注于其 RDS 管控和 Aurora 服務(wù)一樣。在 MySQL 之死上，云廠商也難辭其咎。
逝者不可追，來者猶可待。PostgreSQL 應(yīng)該從 MySQL 上吸取教訓(xùn) —— 盡管 PG 社區(qū)已經(jīng)非常小心地避免出現(xiàn)一家獨大的情況出現(xiàn)，但生態(tài)確實在朝著幾家巨頭云廠商作大壟斷的不利方向發(fā)展。 云正在吞噬開源 —— 云廠商編寫了開源軟件的管控軟件，組建了專家池，通過提供維護(hù)攫取了軟件生命周期中的絕大部分價值，但卻通過搭便車的行為將最大的成本 —— 產(chǎn)研交由整個開源社區(qū)承擔(dān)。 云上 真正有價值的管控/監(jiān)控代碼卻從來不回饋開源社區(qū) —— 在數(shù)據(jù)庫領(lǐng)域，我們已經(jīng)在 MongoDB，ElasticSearch，Redis，以及 MySQL 上看到了這一現(xiàn)象，而 PostgreSQL 社區(qū)確實應(yīng)當(dāng)引以為鑒。 好在 PG 生態(tài)總是不缺足夠頭鐵的人和公司，愿意站出來維護(hù)生態(tài)的平衡，反抗公有云廠商的霸權(quán)。例如，我自己開發(fā)的 PostgreSQL 發(fā)行版 Pigsty，旨在提供一個開箱即用、本地優(yōu)先的開源云數(shù)據(jù)庫 RDS 替代，將社區(qū)自建 PostgreSQL 數(shù)據(jù)庫服務(wù)的底線，拔高到比云廠商 RDS PG 更高的水平線。 而另一個《云計算泥石流[31]》系列專欄則旨在扒開云服務(wù)背后的信息不對稱，從而幫助公有云廠商更加體面，亦稱得上是成效斐然。
盡管我是 PostgreSQL 的堅定支持者，但我也贊同 Peter Zaitsev 的觀點：“如果 MySQL 徹底死掉了，開源關(guān)系型數(shù)據(jù)庫實際上就被 PostgreSQL 一家壟斷了，而壟斷并不是一件好事，因為它會導(dǎo)致發(fā)展停滯與創(chuàng)新減緩。PostgreSQL 要想進(jìn)入全盛狀態(tài)，有一個 MySQL 作為競爭對手并不是壞事”。 —— 至少，MySQL 可以作為一個與鞭策激勵，讓 PostgreSQL 社區(qū)保持凝聚力與危機(jī)感，不斷提高自身的技術(shù)水平，保持開放、透明、公正的社區(qū)治理模式，從而繼續(xù)推動數(shù)據(jù)庫技術(shù)的發(fā)展。 PostgreSQL 帶著開源軟件的初心與愿景繼續(xù)堅定前進(jìn) —— 它將走上 MySQL 未走完的長路，寫完 MySQL 未寫完的詩篇，見到 MySQL 未見的世界，活成 MySQL 未曾活過的愿。在這，謹(jǐn)以一首《PG駛向云外，MySQL安魂九霄》，送給曾經(jīng)的對手 —— MySQL。 PG駛向云外，MySQL安魂九霄我那些殘夢，靈異九霄 徒忙漫奮斗，滿目滄愁 在滑翔之后，完美墜落 在四維宇宙，眩目遨游 我那些爛曲，流竄九州 云游魂飛奏，音憤符吼 在宿命身后，不停揮手 視死如歸仇，毫無保留 黑色的不是夜晚，是漫長的孤單 看腳下一片黑暗，望頭頂星光璀璨 嘆世萬物皆可盼，唯真愛最短暫 失去的永不復(fù)返，世守恒而今倍還 搖旗吶喊的熱情，攜光陰漸遠(yuǎn)去 人世間悲喜爛劇，晝夜輪播不停 紛飛的濫情男女，情仇愛恨別離 一代人終將老去，但總有人正年輕
References
該文章在 2024/7/25 12:30:58 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
