Kiểu danh sách trong mysql

Thiết kế tốt về cả logic vật lý và là những cột lửa quan trọng hướng tới hiệu năng cao, và bạn phải thiết kế lược đồ của mình theo những câu hỏi mà bạn sẽ chạy. Điều này thường dẫn đến việc trao đổi bị mất. Ví dụ như lược đồ không chuẩn hóa có thể tăng tốc một số loại truy vấn nhưng lại làm chậm các loại truy vấn khác. Thêm vào bảng counter và summary là một cách hay để truy vấn tối ưu, nhưng chúng gây khó khăn khi duy trì. Các tính năng của MySQL bị ảnh hưởng một chút từ suy nghĩ trên. Chương này và chương tiếp theo sẽ tập chung vào đánh chỉ mục, xem xét một chút về thiết kế lược đồ. Chúng tôi cho rằng bạn đã biết về cơ sở dữ liệu thiết kế, nên đây không phải là chương để giới thiệu, hay là chương nâng cao. Đây là chương về thiết kế cơ sở dữ liệu MySQL. Chương này là sự chuẩn bị cho 2 chương tiếp theo. Trong chương 3, chúng ta sẽ tìm hiểu sự tương tác của thiết kế logic, thiết kế vật lý và thực thi truy vấn. Điều này yêu cầu toàn bộ sự hiểu biết toàn cảnh và các chi tiết bên trong. Bạn cần hiểu toàn bộ hệ thống để có thể biết được sao các phần nhỏ tương tác với nhau. Bạn có thể thấy nó hữu ích khi đọc chương này trước khi bước vào mục lục chương, tối ưu hóa truy vấn. Rất nhiều thảo luận có liên hệ với nhau nên đọc hết

**Chọn loại dữ liệu tối ưu**

• nhỏ hơn thường tốt hơn. Kiểu dữ liệu nhỏ hơn mà vẫn đáp ứng yêu cầu lưu trữ nhanh hơn vì chúng sử dụng ít bổ sung hơn, ít bộ đệm hơn. Đừng đánh giá thấp khoảng dữ liệu bạn cần chứa vì nó có thể làm tăng dữ liệu ở rất nhiều nơi trong lược đồ và có thể khiến bạn đau đầu, tiêu tốn nhiều thời gian. Nếu bạn đang phân vân cái nào là kiểu dữ liệu tốt nhất thì hãy chọn kiểu nhỏ nhất mà bạn nghĩ nó sẽ k baoh vượt quá đc
• đơn giản là tốt. Đơn giản kiểu dữ liệu giúp chúng ta tiêu tốn ít chu kỳ CPU hơn. Ví dụ số nguyên tốt hơn so với chuỗi vì chuỗi khó so sánh và sắp xếp hơn. Bạn nên sử dụng kiểu dữ liệu tích hợp sẵn của Mysql thay vì sử dụng chuỗi và nên sử dụng số nguyên để biểu diễn địa chỉ IP
• VÔ GIÁ TRỊ. Void null if could. If to default null can be request many memory better data type of it bt. Nếu cột có chỉ mục bị đánh, nó yêu cầu nhiều byte hơn bt và có thể gây ra chỉ mục có kích thước cố định. Cải thiện hiệu suất khi chuyển từ null -> không null thường không tăng nhiều. Không nên đặt trường hợp này có mức độ ưu tiên cao để thay đổi lược đồ. Nếu có ý kiến ​​đánh giá cột chỉ mục thì nên tránh trường hợp null. Kiểu ngày giờ và dấu thời gian chứa cùng 1 kiểu dữ liệu, độ chính xác hàng giây. Nhưng dấu thời gian chỉ sử dụng một nửa bộ nhớ và có khả năng cập nhật tự động. Nhưng nó có phạm vi giá trị nhỏ hơn và gấp đôi khi cái lợi của nó trở thành mặt tiêu cực. Các kiểu Integer, bool, numeric đều là bí danh của 1 kiểu dữ liệu. Nhưng chúng không ảnh hưởng đến hiệu suất. Nếu bạn tạo bảng với bí danh kiểu dữ liệu, khi hiển thị bảng tạo, bạn sẽ thấy kiểu cơ sở

SỐ TOÀN BỘ. Có 2 kiểu số là số nguyên và số thực. If used integer. tinyint, smallint, medinumint, int, or bigint yêu cầu 8, 16, 24, 32 và 64 bit lưu trữ. Số nguyên còn tùy chọn unsigned. MySQL để bạn định nghĩa độ dài của số nguyên như int[11] nhưng nó không có ý nghĩa gì trong hầu hết các ứng dụng. Nó không giới hạn phạm vi giá trị, chỉ hiển thị ra 11 chữ số. Mặc dù khai báo là int[1] nhưng nó có thể chứa đc = int[20]

**SỐ THỰC. ** Dành cho kiểu có phần thực, nhưng vẫn dùng cho kiểu nguyên. FLOAT and DOUBLE support toán học hỗ trợ ~ với dấu , động. Type DECIMAL Support Calculator chính xác phần phân số. Cả 2 kiểu , động và DECIMAL đều có thể xác định chính xác định dạng

LOẠI CHUỖI. VARCHAR & CHAR

• VARCHAR

  • Chuỗi lưu trữ có độ dài < cho trước, thường là thế, còn MyISAM có bảng tạo mà có row_format = fixed thì sẽ sử dụng không gian cố định, cho nên sẽ trả phí không gian
  • Sử dụng thêm 1 hoặc 2 byte để lưu dữ liệu độ dài. 1byte nếu độ dài cột tối đa là 255 byte và 2 nếu nheieuf hơn. Giả sử bộ ký tự latin, varchar[10] sử dụng bộ nhớ 11 byte, varchar[1000] sử dụng 1002 byte
  • Giúp thực hiện tốt vì tiết kiệm không gian. Vì nó dùng thêm biến độ dài nên khi cập nhật thì cần làm thêm 1 số việc. Nếu như độ lớn của nó tăng quá mức khai báo thì phụ thuộc vào động cơ. Nếu MyISAM có thể phân chia hàng, thì InnoDB có thể chia trang nhỏ cho vừa hàng. Những động cơ khác có thể không làm được gì cả
  • Thường sử dụng varchar là hợp lý

• CHAR

  • Char is fixed length, alwaysg lallocate space for value
  • Char is good when used string fixed length as MD5. Tốt hơn varchar khi data hay đc update vì không phải fragment

• Loại BLOB và TEXT. Khác nhau là BLOB lưu kiểu byte nên không cần đối chiếu bộ ký tự ahy còn văn bản thì ngược lại. BLOB and TEXT sort type other. Thay vì sort full length nó chỉ sắp xếp max_sort_length. Mysql không thể lập chỉ mục các trường này nên nó không được sử dụng để sắp xếp

• NGÀY GIỜ VÀ DẤU THỜI GIAN

  • NGÀY GIỜ. năm từ 1001 -> 9999, chính xác hàng s. Dữ liệu của nó được đóng gói ở định dạng int YYYYMMDDHHMMSS, sử dụng 8byte lưu trữ. Can sorted

  • DẤU THỜI GIAN. lưu trữ theo định dạng số giây. Phạm vi từ ngày 1-1-1970. Chỉ có 4 byte lưu trữ. 1970 -> 2038. Mysql có FROM_UNIXTIME[] và UNIX_TIMESTAMP[] chuyển đổi từ dấu thời gian unix thành ngày. And ngc back. Dấu thời gian hiện thị dựa trên múi giờ hệ thống. Khi cập nhật hay chèn 1 hàng mà không có giá trị của dấu thời gian cột thì nó tự động chèn/cập nhật dấu thời gian hiện tại. Dấu thời gian mặc định không đc not null

Lời khuyên

• Sử dụng số nguyên cho định danh. Because it fast and has auto_increment. Line string for Identifiers. Cực kỳ cẩn thận khi sử dụng chuỗi cho mã định danh với MyISAM. Nó sử dụng các chỉ mục đóng gói cho chuỗi mặc định => chậm hơn nhiều

• Cẩn thận với chuỗi “ngẫu nhiên”, ví dụ như chuỗi được sinh ra từ mã băm hàm. Vì nó làm chậm quá trình chèn và chọn vì khó khăn khi đánh index cho những chuỗi ngẫu nhiên

• Quá nhiều cột. Công cụ lưu trữ Mysql hoạt động = cách sao chép hàng giữa máy chủ và công cụ thông qua bộ đệm hàng. Bộ đệm giải mã máy chủ trong cột. Làm thế này sẽ tốn thời gian với Inno và MyISAM ngoại trừ myISAM fixedrow. Thử nghiệm với > 100 cột làm tăng mức tiêu thụ CPU

• Quá nhiều người tham gia. Không nên sử dụng nhiều tham gia. Nếu thực thể mà to quá thì chia ra nhiều bảng để tránh tham gia cả bảng vào

• liệt kê. Cận thận khi sử dụng enum. Ví dụ

CREATE TABLE ... [
country enum['','0','1','2',...,'31']

Trong trường hợp này nên sử dụng khóa ngoại hoặc bảng tra cứu. Nếu bạn muốn thêm một quốc gia mới, thì có cách nào khác ngoài việc sử dụng bảng thay đổi. And in MySQL 5. 0 trở lên, bạn muốn thêm một phần tử vào vị trí nào đi nữa thì nó vẫn ở cuối danh sách

Internations enums dễ gây nhầm lẫn với set. Ví dụ

CREATE TABLE ...[
is_default set['Y','N'] NOT NULL default 'N'

Trong trường hợp này nên sử dụng ENUM thay vì SET. Vì ENUM chỉ cho phép chứa 1 trong 2 giá trị còn SET cho phép chứa 1 -> nhiều giá trị

• VÔ GIÁ TRỊ

Chúng tôi đã viết từ trước về việc tránh sử dụng NULL, và thật lòng chúng tôi đề nghị bạn sử dụng theo một cách khác khi vẫn có thể. Kể cả khi bạn muốn lưu trữ một giá trị “k có giá trị”, bạn cũng không nên sử dụng null. Có thể sử dụng số 0 hoặc 1 giá trị quy ước trước hoặc một chuỗi rỗng. Nhưng trong một số trường hợp sử dụng NULL là tốt hơn và làm cho mã đỡ rắc rối hơn tuy NULL là một lỗi rất khó tránh nhưng nó có thể còn là một cách làm tốt hơn những cái khác. Như đã nhắc từ trước, MySQL has been index for NULL but Oracle then not

• Chuẩn hóa và không chuẩn hóa

  • Ưu điểm/Nhược điểm của Lược đồ chuẩn hóa Mọi người khi yêu cầu trợ giúp về vấn đề hiệu suất thường được khuyến nghị sửa đổi thành lược đồ chuẩn hóa. Đặc biệt nếu khối lượng công việc nặng về ghi

    • Chuẩn hóa thường cập nhật nhanh hơn không chuẩn hóa
    • Khi dữ liệu được chuẩn hóa thì sẽ có ít dữ liệu bị lặp lại, vì vậy ít dữ liệu cần thay đổi hơn
    • Bảng chuẩn hóa thường có kích thước nhỏ hơn, tiết kiệm bộ nhớ và hiệu suất
    • Khi có ít dữ liệu dư thừa đồng nghĩa với việc sử dụng ít DISTINCT và truy vấn GROUP BY
    • Mặt tiêu cực của nó là với những lược đồ chuẩn hóa tốt khi lấy dữ liệu phải sử dụng ít nhất một câu nối. Và phải mất nhiều không gian hơn để đánh chỉ mục

  • Ưu/Nhược điểm của Lược đồ không chuẩn hóa

    • Lược đồ không chuẩn hóa chạy tốt vì tất cả mọi thứ đều nằm trong một bảng nên tránh được việc sử dụng tham gia
    • Nếu bạn không cần tham gia thì câu truy vấn Oăm nhất - khi không sử dụng chỉ mục - là quét toàn bộ bảng. Nhưng nó vẫn có thể nhanh hơn so với tham gia bởi vì nó tránh việc I/O ngẫu nhiên
    • Một bảng đơn có thể có nhiều cách đánh hiệu quả hơn chỉ mục. Ví dụ bạn có một trang web, có người dùng đăng bài và có cả người dùng cao cấp. Nếu muốn xem 10 tin nhắn cuối cùng của người dùng cao cấp với lược đồ đã chuẩn hóa và đánh ngày xuất bản chỉ mục của tin nhắn. Câu truy vấn có giống như sau

Mysql> SELECT message_text, user_name
-> FROM message
-> INNER JOIN user ON message.user_id=user.id
-> WHERE user.account_type=’premiumv’
-> ORDER BY message.published DESC LIMIT 10;

Để thực hiện câu truy vấn này, MySQL cần quét chỉ mục đã xuất bản của bảng thông báo. Mỗi hàng nó tìm được, nó sẽ thăm dò người dùng trong bảng và kiểm tra xem người dùng đó có cao cấp không. Cách này chỉ có hiệu quả khi số lượng nhỏ của người dùng là phí bảo hiểm. Một câu truy vấn khác sẽ bắt đầu từ người dùng bảng, chọn người dùng cao cấp và lấy ra tất cả thư sau đó sắp xếp. Trường hợp này còn tệ hơn. Vấn đề nằm ở chỗ tham gia, nó làm cả 2 công việc là sắp xếp và lọc nhưng chỉ với 1 chỉ mục. Nếu bạn không chuẩn hóa dữ liệu bằng cách xếp nhiều bảng xếp hạng và đánh chỉ mục với [account_type, đã xuất bản], bạn sẽ không cần tham gia và có hiệu quả hơn nhiều

mysql> SELECT message_text,user_name
-> FROM user_messages
-> WHERE account_type='premium'
-> ORDER BY published DESC
-> LIMIT 10;

Một hỗn hợp chuẩn hóa và không chuẩn hóa

Cả normalized và denormalized đều có ưu và nhược điểm. Làm sao chọn được cái nào là thiết kế tốt nhất? . chúng thường không có ý nghĩa gì có thể giới hạn bên ngoài. Trong thế giới bên ngoài, bạn thường kết hợp 2 cách tiếp cận, sử dụng một phần nào đó đã được chuẩn hóa, bảng bộ đệm,. Trong ví dụ trên, thực tế thay vì không chuẩn hóa hoàn toàn bảng thì có thể lưu account_type trên cả bảng người dùng và thông báo. Điều này tránh vấn đề chèn và xóa mất toàn bộ dữ liệu. Bạn sẽ vẫn lưu lại người dùng được mặc dù đã xóa hết tin nhắn. Nó không làm bảng người dùng, thông báo lớn hơn quá nhiều nhưng giúp bạn chọn hiệu quả. Tuy nhiên, bây giờ update user lại khó khăn hơn bởi vì phải thay đổi trên cả 2 bảng. Để xem xét nó có phải là vấn đề thực sự hay không, bạn phải tính toán tần suất thực hiện việc thay đổi có nhiều không và thời gian để hoàn thành thay đổi và so sánh với thời gian thực hiện câu lệnh chọn. Một ví dụ hay khác để chuyển từ bảng cha -> bảng con được sử dụng để sắp xếp. If with normalized schema thì thật là tốn nhiều thời gian để sắp xếp message theo tên tác giả nhưng lược đồ không chuẩn hóa thì nhanh hơn rất nhiều đệm cache và đánh index author_name trong bảng message