Khi sử dụng SQL, có bất kỳ lợi ích của việc sử dụng =trong một WHEREmệnh đề thay vì LIKE?

Nếu không có bất kỳ toán tử đặc biệt nào, LIKEvà =đều giống nhau, phải không?

Người vận hành khác nhau

LIKEvà =là các nhà khai thác khác nhau. Hầu hết các câu trả lời ở đây tập trung vào hỗ trợ ký tự đại diện, đây không phải là điểm khác biệt duy nhất giữa các nhà khai thác này!

=là một toán tử so sánh hoạt động trên các số và chuỗi. Khi so sánh các chuỗi, toán tử so sánh so sánh toàn bộ chuỗi .

LIKElà một toán tử chuỗi so sánh từng ký tự .

Để làm phức tạp vấn đề, cả hai nhà khai thác sử dụng một đối chiếu có thể có tác động quan trọng đến kết quả so sánh.

Ví dụ tạo động lực

Trước tiên chúng ta hãy xác định một ví dụ trong đó các toán tử này tạo ra các kết quả rõ ràng khác nhau. Cho phép tôi trích dẫn từ hướng dẫn sử dụng MySQL:

Theo tiêu chuẩn SQL, THÍCH thực hiện khớp trên cơ sở mỗi ký tự, do đó, nó có thể tạo ra kết quả khác với toán tử so sánh:

mysql> SELECT 'ä' LIKE 'ae' COLLATE latin1_german2_ci;
+-----------------------------------------+
| 'ä' LIKE 'ae' COLLATE latin1_german2_ci |
+-----------------------------------------+
|                                       0 |
+-----------------------------------------+
mysql> SELECT 'ä' = 'ae' COLLATE latin1_german2_ci;
+--------------------------------------+
| 'ä' = 'ae' COLLATE latin1_german2_ci |
+--------------------------------------+
|                                    1 |
+--------------------------------------+

Xin lưu ý rằng trang này của hướng dẫn sử dụng MySQL được gọi là Hàm so sánh chuỗi và =không được thảo luận, hàm ý đó =không hoàn toàn là chức năng so sánh chuỗi.

Làm thế nào không =làm việc?

Các SQL Standard § 8.2 mô tả cách =so sánh chuỗi:

Việc so sánh hai chuỗi ký tự được xác định như sau:

a) Nếu độ dài tính bằng ký tự của X không bằng độ dài tính bằng ký tự của Y, thì chuỗi ngắn hơn được thay thế một cách hiệu quả, với mục đích so sánh, với một bản sao của chính nó đã được mở rộng theo chiều dài của chuỗi dài hơn bằng cách ghép ở bên phải của một hoặc nhiều ký tự pad, trong đó ký tự pad được chọn dựa trên CS. Nếu CS có thuộc tính NO PAD, thì ký tự pad là ký tự phụ thuộc vào triển khai khác với bất kỳ ký tự nào trong bộ ký tự X và Y đối chiếu ít hơn bất kỳ chuỗi nào trong CS. Nếu không, ký tự pad là a.

b) Kết quả so sánh X và Y được đưa ra bởi chuỗi đối chiếu CS.

c) Tùy thuộc vào chuỗi đối chiếu, hai chuỗi có thể so sánh bằng nhau ngay cả khi chúng có độ dài khác nhau hoặc chứa các chuỗi ký tự khác nhau. Khi các hoạt động MAX, MIN, DISTINCT, tham chiếu đến một nhóm nhóm và các toán tử UNION, EXCEPT và INTERSECT tham chiếu đến các chuỗi ký tự, giá trị cụ thể được chọn bởi các hoạt động này từ một tập hợp các giá trị bằng nhau như vậy phụ thuộc vào việc triển khai.

(Nhấn mạnh thêm.)

Điều đó có nghĩa là gì? Nó có nghĩa là khi so sánh các chuỗi, =toán tử chỉ là một trình bao bọc mỏng xung quanh đối chiếu hiện tại. Đối chiếu là một thư viện có các quy tắc khác nhau để so sánh các chuỗi. Đây là một ví dụ về đối chiếu nhị phân từ MySQL :

static int my_strnncoll_binary(const CHARSET_INFO *cs __attribute__((unused)),
                               const uchar *s, size_t slen,
                               const uchar *t, size_t tlen,
                               my_bool t_is_prefix)
{
  size_t len= MY_MIN(slen,tlen);
  int cmp= memcmp(s,t,len);
  return cmp ? cmp : (int)((t_is_prefix ? len : slen) - tlen);
}

Đối chiếu cụ thể này xảy ra để so sánh từng byte (đó là lý do tại sao nó được gọi là "nhị phân" - nó không mang lại bất kỳ ý nghĩa đặc biệt nào cho chuỗi). Các đối chiếu khác có thể cung cấp so sánh nâng cao hơn.

Ví dụ, đây là một đối chiếu UTF-8 hỗ trợ so sánh không phân biệt chữ hoa chữ thường. Mã quá dài để dán ở đây, nhưng đi đến liên kết đó và đọc phần thân của my_strnncollsp_utf8mb4(). Đối chiếu này có thể xử lý nhiều byte cùng một lúc và nó có thể áp dụng các biến đổi khác nhau (chẳng hạn như so sánh không phân biệt chữ hoa chữ thường). Các =nhà điều hành là hoàn toàn trừu tượng từ những thay đổi bất thường của đối chiếu.

Làm thế nào không LIKElàm việc?

Các SQL Standard § 8,5 mô tả cách LIKEso sánh chuỗi:

<Vị ngữ>

M LIKE P

là đúng nếu tồn tại phân vùng M thành các chuỗi con sao cho:

i) Một chuỗi con của M là một chuỗi từ 0 hoặc nhiều hơn <biểu diễn ký tự> s của M và mỗi <biểu diễn ký tự> của M là một phần của chính xác một chuỗi con.

ii) Nếu bộ xác định chuỗi con thứ i của P là một bộ xác định ký tự tùy ý, thì chuỗi con thứ i của M là bất kỳ <biểu diễn ký tự> nào.

iii) Nếu bộ xác định chuỗi con thứ i của P là một bộ xác định chuỗi tùy ý, thì chuỗi con thứ i của M là bất kỳ chuỗi nào từ 0 trở lên <biểu diễn ký tự> s.

iv) Nếu trình xác định chuỗi con thứ i của P không phải là trình xác định ký tự tùy ý cũng không phải là trình xác định chuỗi tùy ý, thì chuỗi con thứ i của M bằng với trình xác định chuỗi con đó theo trình tự đối chiếu của <như vị ngữ>, không có việc thêm các ký tự <dấu cách> vào M và có cùng độ dài với trình xác định chuỗi con đó.

v) Số lượng chuỗi con của M bằng số lượng chỉ định chuỗi con của P.

(Nhấn mạnh thêm.)

Điều này khá dài dòng, vì vậy hãy phá vỡ nó. Các mục ii và iii lần lượt đề cập đến các ký tự đại diện _và %. Nếu Pkhông chứa bất kỳ ký tự đại diện nào, thì chỉ áp dụng mục iv. Đây là trường hợp quan tâm được đặt ra bởi OP.

Trong trường hợp này, nó so sánh từng "chuỗi con" (các ký tự riêng lẻ) Mvới từng chuỗi con trong Pviệc sử dụng đối chiếu hiện tại.

Kết luận

Điểm mấu chốt là khi so sánh các chuỗi, =so sánh toàn bộ chuỗi trong khi LIKEso sánh một ký tự tại một thời điểm. Cả hai so sánh sử dụng đối chiếu hiện tại. Sự khác biệt này dẫn đến kết quả khác nhau trong một số trường hợp, được chứng minh trong ví dụ đầu tiên trong bài viết này.

Bạn nên sử dụng cái nào? Không ai có thể nói với bạn điều đó - bạn cần sử dụng một cái đúng cho trường hợp sử dụng của bạn. Đừng tối ưu hóa sớm bằng cách chuyển đổi các toán tử so sánh.

Toán tử equals (=) là "toán tử so sánh so sánh hai giá trị cho đẳng thức." Nói cách khác, trong một câu lệnh SQL, nó sẽ không trả về true trừ khi cả hai vế của phương trình đều bằng nhau. Ví dụ:

SELECT * FROM Store WHERE Quantity = 200;

Toán tử THÍCH "thực hiện so sánh khớp mẫu" cố gắng khớp "giá trị chuỗi với chuỗi mẫu có chứa các ký tự đại diện." Ví dụ:

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

THÍCH thường chỉ được sử dụng với các chuỗi và bằng (tôi tin) là nhanh hơn. Toán tử bằng coi các ký tự đại diện là ký tự chữ. Sự khác biệt trong kết quả trả về như sau:

SELECT * FROM Employees WHERE Name = 'Chris';

Và

SELECT * FROM Employees WHERE Name LIKE 'Chris';

Sẽ trả về kết quả tương tự, mặc dù việc sử dụng THÍCH thường sẽ mất nhiều thời gian hơn khi kết quả khớp mẫu. Tuy nhiên,

SELECT * FROM Employees WHERE Name = 'Chris%';

Và

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

Sẽ trả về các kết quả khác nhau, khi sử dụng kết quả "=" chỉ kết quả với "Chris%" được trả về và toán tử THÍCH sẽ trả về mọi thứ bắt đầu bằng "Chris".

Mong rằng sẽ giúp. Một số thông tin tốt có thể được tìm thấy ở đây .

Đây là bản sao / dán câu trả lời khác của tôi cho câu hỏi SQL 'like' vs '=' Performance :

Một ví dụ cá nhân sử dụng mysql 5.5: Tôi có một liên kết bên trong giữa 2 bảng, một trong 3 triệu hàng và một trong 10 nghìn hàng.

Khi sử dụng like trên một chỉ mục như bên dưới (không có ký tự đại diện), mất khoảng 30 giây:

where login like '12345678'

sử dụng 'giải thích' tôi nhận được:

Khi sử dụng '=' trên cùng một truy vấn, mất khoảng 0,1 giây:

where login ='12345678'

Sử dụng 'giải thích' tôi nhận được:

Như bạn có thể thấy, việc likehủy bỏ hoàn toàn tìm kiếm chỉ mục, vì vậy truy vấn mất hơn 300 lần thời gian.

LIKEvà =là khác nhau. LIKElà những gì bạn sẽ sử dụng trong một truy vấn tìm kiếm. Nó cũng cho phép các ký tự đại diện như _(ký tự đại diện đơn giản) và %(ký tự đại diện nhiều ký tự).

= nên được sử dụng nếu bạn muốn kết hợp chính xác và nó sẽ nhanh hơn.

Trang web này giải thích LIKE

Một điểm khác biệt - ngoài khả năng sử dụng các ký tự đại diện với THÍCH - là trong các khoảng trắng ở cuối: Toán tử = bỏ qua khoảng trắng ở cuối, nhưng THÍCH thì không.

Phụ thuộc vào hệ thống cơ sở dữ liệu.

Nói chung không có ký tự đặc biệt, có, = và THÍCH là như nhau.

Tuy nhiên, một số hệ thống cơ sở dữ liệu có thể xử lý các cài đặt đối chiếu khác nhau với các toán tử khác nhau.

Chẳng hạn, trong các so sánh MySQL với các chuỗi = on luôn luôn không phân biệt chữ hoa chữ thường, do đó, THÍCH mà không có các ký tự đặc biệt là như nhau. Trên một số RDBMS khác, THÍCH không phân biệt chữ hoa chữ thường trong khi = không.

Trong ví dụ này, chúng tôi chấp nhận rằng varcharcol không chứa ''và không có ô trống đối với cột này

select * from some_table where varcharCol = ''
select * from some_table where varcharCol like ''

Cái đầu tiên dẫn đến đầu ra 0 hàng trong khi cái thứ hai hiển thị toàn bộ danh sách. = là trường hợp khớp hoàn toàn trong khi giống như hoạt động như một bộ lọc. nếu bộ lọc không có tiêu chí, mọi dữ liệu đều hợp lệ.

like - bởi mục đích của nó hoạt động chậm hơn một chút và được thiết kế để sử dụng với varchar và dữ liệu tương tự.

Nếu bạn tìm kiếm một kết quả khớp chính xác, bạn có thể sử dụng cả hai, = và THÍCH.

Sử dụng "=" nhanh hơn một chút trong trường hợp này (tìm kiếm một kết quả khớp chính xác) - bạn có thể tự kiểm tra điều này bằng cách có cùng một truy vấn hai lần trong SQL Server Management Studio, một lần sử dụng "=", một lần bằng cách sử dụng "THÍCH" và sau đó sử dụng "Truy vấn" / "Bao gồm kế hoạch thực hiện thực tế".

Thực hiện hai truy vấn và bạn sẽ thấy kết quả của mình hai lần, cộng với hai kế hoạch thực hiện thực tế. Trong trường hợp của tôi, chúng được chia 50% so với 50%, nhưng kế hoạch thực hiện "=" có "chi phí phụ ước tính" nhỏ hơn (hiển thị khi bạn di chuột qua hộp "CHỌN" bên trái nhất) - nhưng một lần nữa, nó thực sự không phải là một sự khác biệt lớn

Nhưng khi bạn bắt đầu tìm kiếm với các ký tự đại diện trong biểu thức THÍCH của bạn, hiệu suất tìm kiếm sẽ giảm dần. Tìm kiếm "THÍCH Mill%" vẫn có thể khá nhanh - SQL Server có thể sử dụng một chỉ mục trên cột đó, nếu có. Tìm kiếm "THÍCH% biểu thức%" rất chậm, vì cách duy nhất SQL Server có thể đáp ứng tìm kiếm này là quét toàn bộ bảng. Vì vậy, hãy cẩn thận với THÍCH của bạn!

Marc

Sử dụng = tránh các ký tự đại diện và các ký tự đặc biệt xung đột trong chuỗi khi bạn tạo truy vấn khi chạy.

Điều này làm cho cuộc sống của lập trình viên dễ dàng hơn bằng cách không phải thoát khỏi tất cả các ký tự đại diện đặc biệt có thể trượt trong mệnh đề THÍCH và không tạo ra kết quả như mong muốn. Rốt cuộc, = là kịch bản trường hợp sử dụng 99%, sẽ rất khó để thoát khỏi chúng mỗi lần.

trợn tròn mắt ở thập niên 90

Tôi cũng nghi ngờ nó chậm hơn một chút, nhưng tôi nghi ngờ nó có ý nghĩa nếu không có ký tự đại diện trong mẫu.

Để giải quyết câu hỏi ban đầu liên quan đến hiệu suất, nó sử dụng chỉ mục . Khi quét bảng đơn giản xảy ra, "THÍCH" và "=" giống hệt nhau . Khi các chỉ mục được tham gia, nó phụ thuộc vào cách mệnh đề THÍCH được hình thành. Cụ thể hơn, vị trí của ký tự đại diện là gì?

Hãy xem xét những điều sau đây:

CREATE TABLE test(
    txt_col  varchar(10) NOT NULL
)
go

insert test (txt_col)
select CONVERT(varchar(10), row_number() over (order by (select 1))) r
  from master..spt_values a, master..spt_values b
go

CREATE INDEX IX_test_data 
    ON test (txt_col);
go 

--Turn on Show Execution Plan
set statistics io on

--A LIKE Clause with a wildcard at the beginning
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '%10000'
--Results in
--Table 'test'. Scan count 3, logical reads 15404, physical reads 2, read-ahead reads 15416, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index SCAN is 85% of Query Cost

--A LIKE Clause with a wildcard in the middle
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '1%99'
--Results in
--Table 'test'. Scan count 1, logical reads 3023, physical reads 3, read-ahead reads 3018, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost for test data, but it may result in a Table Scan depending on table size/structure

--A LIKE Clause with no wildcards
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO

--an "=" clause = does Index Seek same as above
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col = '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO


DROP TABLE test

Cũng có thể có sự khác biệt không đáng kể trong việc tạo kế hoạch truy vấn khi sử dụng "=" so với "THÍCH".

Bên cạnh các ký tự đại diện, sự khác biệt giữa =AND LIKEsẽ phụ thuộc vào cả loại máy chủ SQL và loại cột.

Lấy ví dụ này:

CREATE TABLE testtable (
  varchar_name VARCHAR(10),
  char_name CHAR(10),
  val INTEGER
);

INSERT INTO testtable(varchar_name, char_name, val)
    VALUES ('A', 'A', 10), ('B', 'B', 20);

SELECT 'VarChar Eq Without Space', val FROM testtable WHERE varchar_name='A'
UNION ALL
SELECT 'VarChar Eq With Space', val FROM testtable WHERE varchar_name='A '
UNION ALL
SELECT 'VarChar Like Without Space', val FROM testtable WHERE varchar_name LIKE 'A'
UNION ALL
SELECT 'VarChar Like Space', val FROM testtable WHERE varchar_name LIKE 'A '
UNION ALL
SELECT 'Char Eq Without Space', val FROM testtable WHERE char_name='A'
UNION ALL
SELECT 'Char Eq With Space', val FROM testtable WHERE char_name='A '
UNION ALL
SELECT 'Char Like Without Space', val FROM testtable WHERE char_name LIKE 'A'
UNION ALL
SELECT 'Char Like With Space', val FROM testtable WHERE char_name LIKE 'A '

• Sử dụng MS SQL Server 2012 , các khoảng trắng ở cuối sẽ được bỏ qua trong phần so sánh, ngoại trừ LIKEkhi kiểu cột là VARCHAR.

• Sử dụng MySQL 5.5 , các khoảng trắng ở cuối sẽ bị bỏ qua =, nhưng không cho LIKE, cả với CHARvà VARCHAR.

• Sử dụng PostgreSQL 9.1 , không gian có ý nghĩa với cả hai =và LIKEsử dụng VARCHAR, nhưng không phải với CHAR(xem tài liệu ).

  Các hành vi với LIKEcũng khác với CHAR.

  Sử dụng cùng một dữ liệu như trên, sử dụng một tường minh CASTtrên tên cột cũng tạo ra sự khác biệt :

  SELECT 'CAST none', val FROM testtable WHERE char_name LIKE 'A'
  UNION ALL
  SELECT 'CAST both', val FROM testtable WHERE
      CAST(char_name AS CHAR) LIKE CAST('A' AS CHAR)
  UNION ALL
  SELECT 'CAST col', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE 'A'
  UNION ALL
  SELECT 'CAST value', val FROM testtable WHERE char_name LIKE CAST('A' AS CHAR)

  Điều này chỉ trả về các hàng cho "CAST cả" và "CAST col".

Từ khóa THÍCH chắc chắn đi kèm với "thẻ giá hiệu năng" được đính kèm. Điều đó nói rằng, nếu bạn có một trường đầu vào có khả năng bao gồm các ký tự đại diện được sử dụng trong truy vấn của bạn, tôi khuyên bạn chỉ nên sử dụng THÍCH nếu đầu vào chứa một trong các thẻ hoang dã. Nếu không, sử dụng các tiêu chuẩn bằng so sánh.

Trân trọng...

Thực sự nó đi xuống những gì bạn muốn truy vấn để làm. Nếu bạn có nghĩa là một kết hợp chính xác thì sử dụng =. Nếu bạn có nghĩa là một trận đấu mờ hơn, sau đó sử dụng THÍCH. Nói những gì bạn muốn nói thường là một chính sách tốt với mã.

Trong Oracle, một 'like' không có ký tự đại diện sẽ trả về kết quả tương tự như 'bằng', nhưng có thể yêu cầu xử lý bổ sung. Theo Tom Kyte , Oracle sẽ coi 'like' không có ký tự đại diện là 'bằng' khi sử dụng bằng chữ, nhưng không phải khi sử dụng biến liên kết.

=và LIKEkhông giống nhau;

1. = khớp với chuỗi chính xác
2. LIKE khớp với một chuỗi có thể chứa ký tự đại diện (%)