TA貢獻1864條經驗 獲得超6個贊
SQL標準（當前版本為ISO / IEC 9075：2011，分為多個部分）對“反勾號”或“反引號”符號（Unicode U + 0060或GRAVE ACCENT）未作任何說明；它不能將其識別為可以在SQL中出現的具有特殊含義的字符。
引用標識符的標準SQL機制是用雙引號引起來的定界標識符：
SELECT "select" FROM "from" WHERE "where" = "group by";
在MySQL中，可以這樣寫：
SELECT `select` FROM `from` WHERE `where` = `group by`;
在MS SQL Server中，可以這樣寫：
SELECT [select] FROM [from] WHERE [where] = [group by];
SQL Standard表示法的問題在于C程序員習慣將字符串括在雙引號中，因此大多數DBMS都將雙引號用作標準所識別的單引號的替代方法。但是，當您要包含標識符時，這就給您帶來了一個問題。
微軟采取了一種方法。MySQL采用了另一個。Informix允許單引號和雙引號的互換使用，但是如果要使用定界的標識符，則可以設置環境變量，然后必須遵循標準（字符串的單引號，標識符的雙引號）。DB2僅遵循標準AFAIK。SQLite似乎遵循該標準。Oracle似乎也遵循該標準。Sybase似乎允許雙引號（標準）或方括號（與MS SQL Server一樣-這意味著SQL Server可能也允許雙引號）。此頁面記錄了所有這些服務器（并幫助填補了我的知識空白），并指出了帶分隔符的標識符中的字符串是否區分大小寫。
至于何時在標識符周圍使用引號機制，我的態度是“從不”。好吧，不是永遠不會，而是只有在絕對被迫這樣做時才這樣做。
注意，分隔標識符區分大小寫；也就是說，"from"并"FROM"引用不同的列（在大多數DBMS中-請參見上面的URL）。大多數SQL都不區分大小寫。知道使用哪種情況很麻煩。（SQL標準具有面向大型機的方向-它希望將名稱轉換為大寫；不過，大多數DBMS會將名稱轉換為小寫。）
通常，您必須界定標識符，這些標識符是所使用的SQL版本的關鍵字。這意味著Standard SQL中的大多數關鍵字，以及所使用的特定實現中的所有其他內容。
麻煩的一個持續根源是升級，其中在發行版N中不是關鍵字的列名將成為發行版N + 1中的關鍵字。在升級之前停止工作的現有SQL之后會停止工作。然后，至少作為短期措施，您可能被迫引用該名稱。但是在正常情況下，您應該避免引用引號。
當然，我的態度因Informix（這是我最常使用的工具）接受此SQL逐字記錄而被大多數DBMS扼制的事實：
CREATE TABLE TABLE
(
DATE INTEGER NOT NULL,
NULL FLOAT NOT NULL,
FLOAT INTEGER NOT NULL,
NOT DATE NOT NULL,
INTEGER FLOAT NOT NULL
);
當然，為演示目的以外的其他目的生產這種可笑桌子的人應該被吊起來，畫好，放進四分之一的位置，然后將殘留物修好以修復他們造成的混亂。但是，在客戶通常設法擊中的某些限制內，關鍵字可以在許多情況下用作標識符。這本身就是一種面向未來的有用形式。如果將單詞變成關鍵字，則現有代碼很有可能會繼續工作而不受更改的影響。但是，該機制并不完善。您無法使用稱為PRIMARY的列創建表，但可以更改表以添加此類列。特質是有原因的，但是很難解釋。
TA貢獻1993條經驗 獲得超6個贊
此外，當sql_mode ANSI_QUOTES處于活動狀態時，MySQL和MariaDB還支持雙qoutes ...- > “ ANSI_QUOTES將”視為標識符引號字符（如`引號字符）而不是字符串引號字符。在啟用此模式的情況下，您仍然可以使用`引用標識符。在啟用ANSI_QUOTES的情況下，您不能使用雙引號對文字字符串加引號，因為它們被解釋為標識符?！?/em>這是符合ANSI SQL標準線..
TA貢獻1893條經驗 獲得超10個贊
盡管我不一定同意，但我非常喜歡這個答案，這使我的知識大為增加，+ 1謝謝。我仍然會繼續使用反引號！:)我更擔心很多老節目突然不能工作，不必查詢傳遞到轉換函數替換用反引號[和] 如果我發生改變數據庫..
舉報