Chữ in hoa có quan trọng trong mysql không?

Nếu máy chủ của bạn đang chạy trên Windows hoặc macOS sử dụng hệ thống tệp phân biệt chữ hoa chữ thường (mặc định cho các Hệ điều hành này) thì bản sao lưu của bạn sẽ hoạt động bình thường trong hầu hết các trường hợp, nhưng việc khôi phục nó trên máy chủ Linux có thể không thành công hoặc gây ra lỗi do tài liệu

Xin lưu ý rằng nguyên nhân gốc rễ của các sự cố khôi phục mà bạn có thể gặp phải là sự cố trong chính máy chủ cơ sở dữ liệu MySQL / MariaDB / Percona, không phải sự cố có thể khắc phục được trong phần mềm của chúng tôi. Giải quyết vấn đề này yêu cầu cấu hình đúng của máy chủ cơ sở dữ liệu (cài đặt đúng lower_case_table_names trên máy chủ cơ sở dữ liệu Windows / macOS, tùy thuộc vào cài đặt trên máy chủ Linux tương ứng) TRƯỚC KHI tạo các bảng có chữ hoa trong đó. Một lần nữa, điều này được ghi lại bởi chính MySQL

Nếu máy chủ của bạn đang chạy trên Linux HOẶC hệ thống tệp phân biệt chữ hoa chữ thường (e. g. HFS+ Case-Sensitive trên macOS) HOẶC bạn đã định cấu hình đúng máy chủ cơ sở dữ liệu của mình SAU ĐÓ và chỉ khi đó bạn mới có thể bỏ qua thông báo này một cách an toàn

Akeeba Backup / Akeeba Solo đã phát hiện ra rằng ít nhất một trong các cơ sở dữ liệu của bạn có một hoặc nhiều chữ cái viết hoa trong tiền tố tên bảng cơ sở dữ liệu

Khôi phục sao lưu ngay cả trên cùng một máy chủ có thể không thành công nếu bạn có các bảng có khóa/quan hệ ngoại vì MySQL không cho phép Akeeba Backup phát hiện chính xác quan hệ giữa các bảng. Bạn có thể sử dụng tùy chọn Chặn kiểm tra khóa ngoại của tập lệnh khôi phục để khôi phục bản sao lưu nhưng KHÔNG đảm bảo tính toàn vẹn của dữ liệu trong trường hợp này

Nếu bạn có các bảng sử dụng cùng một tiền tố trong các trường hợp chữ cái khác nhau (e. g. FOO_bar và foo_bar) sau đó và chỉ khi đó bản sao lưu SẼ KHÔNG THÀNH CÔNG với lỗi MySQL tương tự như "bảng FOO_bar không tồn tại". Điều này sẽ khiến việc sao lưu trang web của bạn hoàn toàn không thể thực hiện được

Hơn nữa, xin lưu ý rằng trong hầu hết các trường hợp, sẽ không thể thay đổi tiền tố cơ sở dữ liệu khi khôi phục trang web về máy chủ Linux

Cuối cùng, điều này sẽ gây ra sự cố khôi phục khi chuyển trang web từ Windows/macOS sang Linux hoặc từ Windows/macOS sang một số máy chủ macOS có hệ thống tệp phân biệt chữ hoa chữ thường, đặc biệt nếu sử dụng phiên bản MySQL cũ hơn. Đây là sự cố MySQL, được ghi lại trong trang web riêng của MySQL. Vui lòng không liên hệ với chúng tôi để được hỗ trợ nếu bạn chọn bỏ qua cảnh báo này và khôi phục trang web của bạn không thành công

Bản chất của vấn đề

Vấn đề là cách MySQL xử lý phân biệt chữ hoa chữ thường của các bảng và các thành phần cơ sở dữ liệu khác trên các hệ thống tệp không phân biệt chữ hoa chữ thường (mặc định trên Windows và macOS)

Vui lòng đọc trang tài liệu của MySQL giải thích vấn đề phân biệt chữ hoa chữ thường. Xét cho cùng, nguyên nhân gốc rễ của vấn đề này là do một hành vi MySQL được ghi lại mà chúng tôi không thể giải quyết được. Nó yêu cầu định cấu hình máy chủ cơ sở dữ liệu TRƯỚC KHI tạo các bảng có chữ hoa trong đó, chính xác như trang tài liệu MySQL giải thích rất rõ ràng

Nếu trang web bạn đang sao lưu nằm trên hệ thống tệp không phân biệt chữ hoa chữ thường (mặc định trên Windows và macOS) và lower_case_table_names được đặt thành 1 (mặc định trên Windows) thì MySQL sẽ báo cáo tất cả các bảng cơ sở dữ liệu có tên viết thường. Giả sử tiền tố cơ sở dữ liệu của trang web của bạn là Foo_. Một bảng thuộc trang web của bạn có tên là Foo_bar sẽ được báo cáo là foo_bar. Tuy nhiên, Sao lưu Akeeba ĐÚNG coi foo_bar không bắt đầu bằng tiền tố của trang được định cấu hình (Foo_) vì tên bảng cơ sở dữ liệu phân biệt chữ hoa chữ thường

Điều này có một số tác động quan trọng khi thực hiện sao lưu

• Một số bộ lọc cơ sở dữ liệu tự động sẽ không hoạt động vì chúng dự kiến ​​chỉ áp dụng cho các bảng chính (bảng bắt đầu bằng tiền tố bảng cơ sở dữ liệu được định cấu hình của trang web)

• Bộ lọc cơ sở dữ liệu thủ công của bạn có thể không hoạt động. Trong trường hợp này, bạn cũng sẽ thấy bảng được báo cáo trong trang Bộ lọc bảng cơ sở dữ liệu dưới dạng foo_bar thay vì #__bar

• Akeeba Backup không thể phát hiện mối quan hệ giữa các bảng có thể gây ra sự cố khôi phục

• Không thể thay đổi tiền tố cơ sở dữ liệu khi khôi phục vì Akeeba Backup sẽ chỉ đổi tên các bảng được coi là bảng cốt lõi (bảng bắt đầu bằng tiền tố bảng cơ sở dữ liệu được định cấu hình của trang web) trong thời gian sao lưu

• Nếu bạn có các bảng có tiền tố viết hoa, e. g. Foo_bar và đổi tên chúng thành chữ thường HOẶC tạo tên chữ thường có cùng tiền tố (e. g. foo_bar) MySQL kết thúc với HAI định nghĩa bảng (FOO_bar và foo_bar) nhưng MỘT bộ tệp cho các bảng này. Điều này sẽ khiến sao lưu không thành công với lỗi MySQL tương tự như "bảng FOO_bar không tồn tại". Đây là sự cố MySQL được ghi lại (xem liên kết được cung cấp ở trên)

Nếu trang web mà bạn đang sao lưu nằm trên hệ thống tệp không phân biệt chữ hoa chữ thường (mặc định trên Windows và macOS) và lower_case_table_names được đặt thành 2 (mặc định trên macOS) thì hầu hết các vấn đề này đều được giải quyết miễn là cài đặt này có hiệu lực TRƯỚC các bảng có . e. trước khi trang web của bạn được cài đặt. Nếu bạn cố gắng thay đổi nó sau khi trang web của bạn đã được cài đặt thì tốt nhất bản sao lưu của bạn sẽ gặp sự cố khôi phục, tệ nhất là bạn sẽ không thể truy cập trang web của mình

Dung dịch

Phòng bệnh hơn chữa bệnh. KHÔNG BAO GIỜ, BAO GIỜ SỬ DỤNG TIỀN TỆ TÊN BẢNG CHỮ HOA. Nếu bạn làm như vậy, bạn đang thực sự khó chuyển trang web của mình giữa các máy chủ một cách đáng tin cậy trừ khi bạn đã hết sức cẩn thận khi định cấu hình máy chủ cơ sở dữ liệu trên Windows / macOS

Nếu bạn gặp khó khăn với một trang web sử dụng tiền tố tên bảng viết hoa hoặc viết hoa hỗn hợp, bạn cần chuyển đổi nó thành tiền tố viết thường. Điều này thường có thể thực hiện được với Akeeba Backup và Akeeba Solo. Cách thực hiện tùy thuộc vào cấu hình máy chủ cơ sở dữ liệu MySQL và hệ điều hành bạn đang sử dụng

Có một số trường hợp quy trình được mô tả bên dưới sẽ không thành công. Một lần nữa, đây là sự cố với MySQL được ghi lại trong trang web riêng của MySQL

Nếu điều này xảy ra, vui lòng không yêu cầu chúng tôi hỗ trợ. Thay vào đó, hoàn tác bất kỳ. cnf thay đổi cấu hình bạn đã thực hiện, khởi động lại máy chủ cơ sở dữ liệu, xóa cơ sở dữ liệu MySQL của bạn, tạo mới và khôi phục lại bản sao lưu. Quá trình khôi phục này SẼ hoạt động, tuy nhiên, trang web của bạn chưa thể được chuyển sang máy chủ khác. Bạn sẽ phải áp dụng cách khắc phục thủ công, phức tạp được mô tả ở gần cuối trang được liên kết trong đoạn trên

Vui lòng lưu ý rằng chúng tôi không thể cung cấp bất kỳ hỗ trợ nào ngoài những gì được thảo luận trong tài liệu này về vấn đề này, mà cuối cùng là cấu hình sai của trang web của bạn (điều gì đó dưới sự kiểm soát duy nhất của bạn) trong bối cảnh máy chủ cơ sở dữ liệu của bạn hoạt động như thế nào (điều gì đó khách quan không thuộc về chúng tôi hoặc của bạn).

Nếu bạn đang dùng Linux HOẶC macOS với hệ thống tệp phân biệt chữ hoa chữ thường

1. Sao lưu trang web của bạn bằng Akeeba Backup hoặc Akeeba Solo

2. Xóa tất cả các bảng của trang web của bạn khỏi cơ sở dữ liệu trang web của bạn. Ngoài ra, bạn có thể tạo một cơ sở dữ liệu mới

   
   Quan trọng

   KHÔNG để lại các bảng cũ trong cơ sở dữ liệu

3. Khôi phục bản sao lưu. Khi bạn đến trang Khôi phục cơ sở dữ liệu của trang web, hãy tìm Tiền tố tên bảng cơ sở dữ liệu và đặt tiền tố đó thành tất cả các ký tự chữ thường. Ví dụ: nếu là FbZt_, hãy đổi nó thành fbzt_

   MySQL là trường hợp

   Tên bảng và cơ sở dữ liệu được lưu trữ trên đĩa bằng cách sử dụng chữ cái được chỉ định trong câu lệnh CREATE TABLE hoặc CREATE DATABASE, nhưng MySQL chuyển đổi chúng thành chữ thường khi tra cứu. So sánh tên không phân biệt chữ hoa chữ thường . Điều này chỉ hoạt động trên các hệ thống tệp không phân biệt chữ hoa chữ thường.

   Là trường hợp MySQL

   Tên cột, chỉ mục, quy trình được lưu trữ và tên sự kiện không phân biệt chữ hoa chữ thường trên bất kỳ nền tảng nào , cũng như bí danh cột. Tuy nhiên, tên của các nhóm logfile phân biệt chữ hoa chữ thường. Điều này khác với SQL tiêu chuẩn.

   Tại sao MySQL lại viết hoa toàn bộ?

   Việc tuân thủ tiêu chuẩn có tất cả từ khóa viết hoa ngăn chặn việc những người liên quan có thể quét tìm từ khóa dễ dàng . Phân biệt chữ hoa chữ thường không giới hạn đối với MySQL. Hầu hết các công cụ SQL không phân biệt chữ hoa chữ thường.

   Một truy vấn có thể được viết trong bất kỳ trường hợp nào trong MySQL không?

   Các đối chiếu mặc định được SQL Server và MySQL sử dụng không phân biệt chữ hoa và chữ thường— chúng không phân biệt chữ hoa chữ thường theo mặc định . Logic của truy vấn này là hoàn toàn hợp lý nhưng kế hoạch thực hiện thì không. DB2.