我正在使用兩個資料庫，一個是 MS SQL Server，另一個是 SQLite。兩者都包含我可以并且已經驗證的相同資料（至少，它們在不同語言允許的范圍內是相同的）。在使用這兩種語言時，我發現兩種語言的執行方式存在令人困惑的差異：
當我在 SQL Server 中運行以下查詢時：
SELECT
count(*)
FROM
Pattern as p
WHERE
'RK69M|1M116849' like replace(p.Keys, '*', '_') '%'
我得到：
47040
但是當我在 SQLite 中運行等效查詢時（唯一的區別是 SQL Server 中的連接是 SQLite 使用||）：
SELECT
count(*)
FROM
Pattern as p
WHERE
'RK69M|1M116849' like replace(p.Keys, '*', '_') || '%'
我得到：43197
誰能解釋一下？他們是否使用不同的正則運算式進行匹配？
如果這兩者都很重要，表中的記錄數（洗掉where子句）是1304884
我還嘗試通過多個渠道（TSQL、python、基于 GUI 的查詢工具等）運行查詢，并且都得到相同的結果。我還使用 python 腳本測驗了資料以比較它們并將它們轉儲到文本檔案并在 linux 中使用 diff 命令，因此我相信每個資料庫中的資料都是相同的。
uj5u.com熱心網友回復：
[在 SQL Server 中] 我得到：47040
[在 Sqlite 中] 我得到：43197
誰能解釋一下？他們是否使用不同的正則運算式進行匹配？
它根本不是正則運算式。LIKE是它自己的東西。但就像這類問題經常出現的情況一樣，我們可以通過查看檔案來獲得洞察力。
這是 SQL Server 的 LIKE 運算子檔案
SQL Server 的相關部分描述了四種不同的模式匹配標記：%、_、[]和[^ ]
這是 Sqlite 的檔案
（向下滾動到第 5 節）
相關部分僅描述前兩個模式標記：%和_.
這兩個資料庫的檔案都包含有關轉義字符等其他資訊以及查詢中未使用的內容，但 Sqlite 檔案包括以下內容：
默認情況下，LIKE 運算子對超出 ASCII 范圍的 unicode 字符區分大小寫。
我不知道您的資料的性質或這是否重要，但我可以說 SQL Server 對同一問題的處理取決于排序規則，因此不一定相同。
關鍵是兩個資料庫引擎在該領域的行為方式存在記錄差異，因此在給出重要資料的情況下，您應該期望得到一些不同的結果。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/461142.html
下一篇：在特定號碼上設定唯一欄位