Vì bạn đặt tiền thưởng, tôi sẽ chia sẻ những bí mật khó giành được của tôi ...
Nói chung, tất cả các SQL mà tôi đã điều chỉnh ngày hôm nay đều yêu cầu sử dụng truy vấn phụ. Đến từ thế giới cơ sở dữ liệu Oracle, những thứ tôi cho là đương nhiên không hoạt động giống như vậy với MySQL. Và bài đọc của tôi về điều chỉnh MySQL khiến tôi kết luận rằng MySQL đứng sau Oracle về việc tối ưu hóa các truy vấn.
Mặc dù các truy vấn đơn giản cần thiết cho hầu hết các ứng dụng B2C có thể hoạt động tốt cho MySQL, nhưng hầu hết các loại truy vấn tổng hợp cần thiết cho Báo cáo thông minh dường như yêu cầu một chút lập kế hoạch và tổ chức lại các truy vấn SQL để hướng dẫn MySQL thực thi chúng nhanh hơn.
Quản trị:
max_connections là số lượng kết nối đồng thời. Giá trị mặc định là 100 kết nối (151 kể từ 5.0) - rất nhỏ.
Lưu ý:
kết nối chiếm bộ nhớ và hệ điều hành của bạn có thể không xử lý được nhiều kết nối.
Các mã nhị phân MySQL cho Linux / x86 cho phép bạn có tới 4096 kết nối đồng thời, nhưng các mã nhị phân tự biên dịch thường có ít giới hạn hơn.
Đặt table_cache để khớp với số lượng bảng đang mở và các kết nối đồng thời của bạn. Theo dõi giá trị open_tables và nếu giá trị này đang tăng nhanh, bạn sẽ cần phải tăng kích thước của nó.
Lưu ý:
2 tham số trước đó có thể yêu cầu rất nhiều tệp đang mở. 20 + max_connections + table_cache * 2 là một ước tính tốt cho những gì bạn cần. MySQL trên Linux có tùy chọn open_file_limit, hãy đặt giới hạn này.
Nếu bạn có các truy vấn phức tạp thì sort_buffer_size và tmp_table_size có thể rất quan trọng. Giá trị sẽ phụ thuộc vào độ phức tạp của truy vấn và các tài nguyên có sẵn, nhưng 4Mb và 32Mb, tương ứng là các điểm khởi đầu được khuyến nghị.
Lưu ý:Đây là các giá trị "mỗi kết nối", trong số read_buffer_size, read_rnd_buffer_size và một số giá trị khác, có nghĩa là giá trị này có thể cần cho mỗi kết nối. Vì vậy, hãy xem xét tải của bạn và tài nguyên có sẵn khi thiết lập các thông số này. Ví dụ:sort_buffer_size chỉ được cấp phát nếu MySQL cần thực hiện sắp xếp. Lưu ý:hãy cẩn thận để không hết bộ nhớ.
Nếu bạn đã thiết lập nhiều kết nối (tức là một trang web không có kết nối liên tục), bạn có thể cải thiện hiệu suất bằng cách đặt thread_cache_size thành giá trị khác 0. 16 là giá trị tốt để bắt đầu. Tăng giá trị cho đến khi thread_create của bạn không phát triển quá nhanh.
TỪ KHÓA CHÍNH:
Mỗi bảng chỉ được có một cột AUTO_INCREMENT, nó phải được lập chỉ mục và không được có giá trị DEFAULT
KEY thường là từ đồng nghĩa với INDEX. Thuộc tính khóa PRIMARY KEY cũng có thể được chỉ định chỉ là KEY khi được đưa ra trong định nghĩa cột. Điều này đã được triển khai để tương thích với các hệ thống cơ sở dữ liệu khác.
KHÓA CHÍNH là một chỉ mục duy nhất trong đó tất cả các cột chính phải được xác định là KHÔNG ĐẦY ĐỦ
Nếu chỉ mục CHÍNH hoặc CHỈ SỐ DUY NHẤT chỉ bao gồm một cột có kiểu số nguyên, bạn cũng có thể tham chiếu đến cột là "_rowid" trong câu lệnh CHỌN.
Trong MySQL, tên của một KHÓA CHÍNH là CHÍNH
Hiện tại, chỉ có bảng InnoDB (v5.1?) Hỗ trợ khóa ngoại.
Thông thường, bạn tạo tất cả các chỉ mục bạn cần khi tạo bảng. Bất kỳ cột nào được khai báo là CHÍNH, KEY, UNIQUE hoặc INDEX sẽ được lập chỉ mục.
NULL có nghĩa là "không có giá trị". Để kiểm tra NULL, bạn không thể sử dụng các toán tử so sánh số học như =,
NO_AUTO_VALUE_ON_ZERO ngăn tự động tăng số 0 để chỉ NULL tạo ra số thứ tự tiếp theo. Chế độ này có thể hữu ích nếu 0 đã được lưu trữ trong cột AUTO_INCREMENT của bảng. (Nhân tiện, lưu trữ số 0 không phải là phương pháp được khuyến khích.)
Để thay đổi giá trị của bộ đếm AUTO_INCREMENT được sử dụng cho các hàng mới:
ALTER TABLE mytable AUTO_INCREMENT = value;
orSET INSERT_ID =value;
Trừ khi được chỉ định khác, giá trị sẽ bắt đầu bằng:1000000 hoặc chỉ định nó như vậy:
...) ENGINE =MyISAM DEFAULT CHARSET =latin1 AUTO_INCREMENT =1
LẦN THỬ NGHIỆM:
Giá trị cho cột TIMESTAMP được chuyển đổi từ múi giờ hiện tại sang UTC để lưu trữ và từ UTC sang múi giờ hiện tại để truy xuất.
http://dev.mysql.com/doc/refman/5.1 /en/timestamp.html Đối với một cột TIMESTAMP trong bảng, bạn có thể chỉ định dấu thời gian hiện tại làm giá trị mặc định và giá trị tự động cập nhật.
một điều cần lưu ý khi sử dụng một trong các loại này trong mệnh đề WHERE, tốt nhất là doWHERE datecolumn =FROM_UNIXTIME (1057941242) và notWHERE UNIX_TIMESTAMP (datecolumn) =1057941242. làm theo kiểu sau sẽ không tận dụng được chỉ mục trên đó cột.
http://dev.mysql.com /doc/refman/5.1/en/date-and-time-functions.html
UNIX_TIMESTAMP()
FROM_UNIXTIME()
UTC_DATE()
UTC_TIME()
UTC_TIMESTAMP()
nếu bạn chuyển đổi datetime sang unix timestamp trong MySQL:
Và sau đó thêm 24 giờ vào nó:
Và sau đó chuyển đổi nó trở lại datetime thì kỳ diệu sẽ mất một giờ!
Đây là những gì đang xảy ra. Khi chuyển đổi dấu thời gian unix trở lại ngày giờ, múi giờ được xem xét và điều đó xảy ra là từ ngày 28 đến ngày 29 tháng 10 năm 2006, chúng tôi đã đi tắt thời gian tiết kiệm ánh sáng ban ngày và mất một giờ.
Bắt đầu với MySQL 4.1.3, các hàm CURRENT_TIMESTAMP (), CURRENT_TIME (), CURRENT_DATE () và FROM_UNIXTIME () trả về giá trị trong múi giờ hiện tại của kết nối , có sẵn dưới dạng giá trị của biến hệ thống múi giờ. Ngoài ra, UNIX_TIMESTAMP () giả định rằng đối số của nó là một giá trị datetime trong múi giờ hiện tại.
Cài đặt múi giờ hiện tại không ảnh hưởng đến các giá trị được hiển thị bởi các hàm như UTC_TIMESTAMP () hoặc các giá trị trong cột DATE, TIME hoặc DATETIME.
LƯU Ý:CẬP NHẬT CHỈ CÒN cập nhật DateTime nếu một trường bị thay đổi Nếu một CẬP NHẬT dẫn đến không có trường nào được thay đổi thì DateTime KHÔNG được cập nhật!
Ngoài ra, TIMESTAMP đầu tiên luôn được TỰ ĐỘNG HÓA theo mặc định ngay cả khi không được chỉ định
Khi làm việc với Dates, tôi hầu như luôn chuyển tải đến Julian Date becuase Toán dữ liệu sau đó là một vấn đề đơn giản về cộng hoặc trừ các số nguyên và Giây kể từ Nửa đêm vì lý do tương tự. Hiếm khi tôi cần thời gian thay đổi độ chi tiết nhỏ hơn giây.
Cả hai đều có thể được lưu trữ dưới dạng số nguyên 4 byte và nếu không gian thực sự chật hẹp, có thể được kết hợp thành thời gian UNIX (giây kể từ kỷ nguyên 1/1/1970) dưới dạng số nguyên không dấu sẽ tốt cho đến khoảng năm 2106 như sau:
'giây sau 24Hrs =86400
'Số nguyên đã ký max val =2.147.483.647 - có thể giữ 68 năm giây
'Số nguyên chưa ký max val =4,294,967,295 - có thể giữ 136 năm Giây
Giao thức nhị phân:
MySQL 4.1 đã giới thiệu một giao thức nhị phân cho phép các giá trị dữ liệu không phải chuỗi được gửi và trả về ở định dạng gốc mà không cần chuyển đổi sang và từ định dạng chuỗi. (Rất hữu ích)
Ngoài ra, mysql_real_query () nhanh hơn mysql_query () vì nó không gọi strlen () để hoạt động trên chuỗi câu lệnh.
http://dev.mysql.com/tech-resources /articles/4.1/prepared-statements.html Giao thức nhị phân hỗ trợ các câu lệnh chuẩn bị từ phía máy chủ và cho phép truyền các giá trị dữ liệu ở định dạng gốc. Giao thức nhị phân đã trải qua khá nhiều sửa đổi trong các bản phát hành trước đó của MySQL 4.1.
Bạn có thể sử dụng macro IS_NUM () để kiểm tra xem một trường có kiểu số hay không. Phân loại giá trị cho IS_NUM () và nó cho giá trị TRUE nếu trường là số:
Một điều cần lưu ý là dữ liệu nhị phân CÓ THỂ được gửi bên trong một truy vấn thông thường nếu bạn thoát khỏi nó và nhớ rằng MySQL yêu cầu chỉ đó là dấu gạch chéo ngược và ký tự trích dẫn được thoát. Vì vậy, đó là một cách thực sự dễ dàng để CHÈN các chuỗi nhị phân ngắn hơn như mật khẩu được mã hóa / muối chẳng hạn.
Máy chủ chính:
http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html
http://www.databasejournal.com/features/mysql/article.php / 10897_3355201_2
CẤP PHÉP THAY THẾ CHẬM TRÊN . tới slave_user IDENTIFIED BY 'slave_password'
#Master Binary Logging Config STATEMENT causes replication
to be statement-based - default
log-bin=Mike
binlog-format=STATEMENT
server-id=1
max_binlog_size = 10M
expire_logs_days = 120
#Slave Config
master-host=master-hostname
master-user=slave-user
master-password=slave-password
server-id=2
Tệp nhật ký nhị phân phải đọc:
http://dev.mysql.com/doc/refman /5.0/en/binary-log.html
http://www.mydigitallife.info/2007/10/06/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/
http://dev.mysql.com/doc/refman/5.1 /en/mysqlbinlog.html
http://dev.mysql.com/doc/refman /5.0/en/binary-log.html
http://dev.mysql.com/doc /refman/5.1/en/binary-log-setting.html
Bạn có thể xóa tất cả các tệp nhật ký nhị phân bằng câu lệnh RESET MASTER hoặc một tập hợp con của chúng bằng PURGE MASTER
--result-file =binlog.txt TrustedFriend-bin.000030
Chuẩn hóa:
http://dev.mysql.com/tech-resources /articles/intro-to-normalization.html
Các chức năng của UDF
http://www.koders.com/cpp/fid10666379322B54AD41AEB0E4100D87C8CDDF1D8
http://souptonuts.sourceforge.net/readme_mysql.htm
Kiểu dữ liệu:
http://dev.mysql.com/doc/refman /5.1/en/storage-requirements.html
http://www.informit.com/articles/article.aspx ? p =1238838 &seqNum =2
http://bitfilm. net / 2008/03/24 / save-byte-performance-data-storage-mysql-part-1 /
Một điều cần lưu ý là trên một bảng hỗn hợp có cả CHAR và VARCHAR, mySQL sẽ thay đổi CHAR thành VARCHAR's
RecNum integer_type UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (RecNum)
MySQL luôn thể hiện các ngày bằng năm đầu tiên, phù hợp với các thông số kỹ thuật tiêu chuẩn của SQL và ISO 8601
Khác:
Việc loại bỏ một số chức năng MySQl sẽ dẫn đến các tệp dữ liệu nhỏ hơn và truy cập nhanh hơn. Ví dụ:
--datadir sẽ chỉ định thư mục dữ liệu và
--skip-innodb sẽ tắt tùy chọn đổi mới và giúp bạn tiết kiệm 10-20 triệu
Thêm tại đây http://dev.mysql.com/tech -resources / posts / mysql-c-api.html
Tải xuống Chương 7 - Miễn phí
InnoDB là giao dịch nhưng có một chi phí hiệu suất đi kèm với nó. Tôi nhận thấy rằng các bảng MyISAM là đủ cho 90% các dự án của tôi.
không có chi phí giao dịch:
Nhanh hơn nhiều
Yêu cầu dung lượng đĩa thấp hơn
Cần ít bộ nhớ hơn để thực hiện cập nhật
Mỗi bảng MyISAM được lưu trữ trên đĩa trong ba tệp. Các tệp có tên bắt đầu bằng tên bảng và có phần mở rộng để chỉ ra loại tệp. Tệp .frm lưu trữ định dạng bảng. Tệp dữ liệu có phần mở rộng .MYD (MYData). Tệp chỉ mục có phần mở rộng .MYI (MYIndex).
Những Tệp này có thể được sao chép nguyên vẹn vào vị trí lưu trữ mà không cần sử dụng tính năng Sao lưu quản trị viên MySQL, việc này tốn thời gian (Khôi phục cũng vậy)
Bí quyết là tạo một bản sao của các tệp này sau đó XÓA bảng. Khi bạn đặt lại các tệp, MySQl sẽ nhận ra chúng và cập nhật theo dõi bảng.
Nếu bạn phải Sao lưu / Khôi phục,
Việc khôi phục bản sao lưu hoặc nhập từ tệp kết xuất hiện có có thể mất nhiều thời gian tùy thuộc vào số lượng chỉ mục và khóa chính bạn có trên mỗi bảng. Bạn có thể tăng tốc quá trình này lên đáng kể bằng cách sửa đổi tệp kết xuất ban đầu của mình bằng cách bao quanh nó bằng những thứ sau:
SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;
.. your dump file ..
SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;
Để tăng đáng kể tốc độ tải lại, hãy thêm lệnh SQL SET AUTOCOMMIT =0; ở đầu tệp kết xuất và thêm COMMIT; lệnh đến cùng.
Theo mặc định, autocommit được bật, có nghĩa là mỗi và mọi lệnh chèn vào tệp kết xuất sẽ được coi là một giao dịch riêng biệt và được ghi vào đĩa trước khi lệnh tiếp theo được bắt đầu. Nếu bạn không thêm các lệnh này, việc tải lại cơ sở dữ liệu lớn vào InnoDB có thể mất nhiều giờ ...
Kích thước tối đa của một hàng trong bảng MySQL là 65,535 byte
Độ dài tối đa hiệu dụng của một VARCHAR trong MySQL 5.0.3 và on =kích thước hàng tối đa (65,535 byte)
Giá trị VARCHAR không được đệm khi chúng được lưu trữ. Khoảng trắng sau được giữ lại khi các giá trị được lưu trữ và truy xuất, tuân theo SQL tiêu chuẩn.
Giá trị CHAR và VARCHAR trong MySQL được so sánh mà không liên quan đến dấu cách ở cuối.
Sử dụng CHAR sẽ chỉ tăng tốc độ truy cập của bạn nếu toàn bộ bản ghi có kích thước cố định. Có nghĩa là, nếu bạn sử dụng bất kỳ đối tượng có kích thước thay đổi nào, bạn cũng có thể làm cho tất cả chúng có kích thước thay đổi. Bạn không tăng tốc độ bằng cách sử dụng CHAR trong bảng cũng chứa VARCHAR.
Giới hạn VARCHAR 255 ký tự đã được nâng lên 65535 ký tự kể từ MySQL 5.0.3
Tìm kiếm toàn văn bản chỉ được hỗ trợ cho các bảng MyISAM.
http://dev.mysql.com/doc/refman /5.0/en/fulltext-search.html
Cột BLOB không có bộ ký tự và việc sắp xếp và so sánh dựa trên giá trị số của các byte trong giá trị cột
Nếu chế độ SQL nghiêm ngặt không được bật và bạn chỉ định giá trị cho cột BLOB hoặc TEXT vượt quá độ dài tối đa của cột, giá trị sẽ bị cắt bớt cho vừa và cảnh báo sẽ được tạo.
Các lệnh hữu ích:
kiểm tra chế độ nghiêm ngặt:SELECT @@ global.sql_mode;
tắt chế độ nghiêm ngặt:
SET @@ global.sql_mode ='';
SET @@ global.sql_mode ='MYSQL40'
hoặc xóa:sql-mode ="STRICT_TRANS_TABLES, ...
HIỂN THỊ CÁC CỘT TỪ mytable
CHỌN tối đa (số lượng tên) AS virtualcolumn TỪ LỆNH trong bảng của tôi THEO cột ảo
http://dev.mysql.com /doc/refman/5.0/en/group-by-hiised-fields.html
http://dev.mysql .com / doc / refman / 5.1 / vi / information-functions.html # function_last-insert-id last_insert_id ()
giúp bạn có PK của hàng cuối cùng được chèn vào tối đa của chủ đề hiện tại (pkcolname) giúp bạn có PK cuối cùng về tổng thể.
Lưu ý:nếu bảng trống, max (pkcolname) trả về 1 mysql_insert_id () chuyển đổi kiểu trả về của hàm MySQL C API gốc mysql_insert_id () thành kiểu oflong (được đặt tên là int trong PHP).
Nếu cột AUTO_INCREMENT của bạn có loại cột là BIGINT, giá trị domysql_insert_id () trả về sẽ không chính xác. Thay vào đó, hãy sử dụng hàm MySQL SQL nội bộ LAST_INSERT_ID () trong truy vấn SQL.
Chỉ cần lưu ý rằng khi bạn đang cố gắng chèn dữ liệu vào bảng và bạn gặp lỗi:
Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’
sử dụng một cái gì đó như
INSERT INTO table (this, that) VALUES ($this, $that)
đó là bởi vì bạn không có bất kỳ dấu nháy đơn nào xung quanh các giá trị mà bạn đang cố gắn vào bảng. Vì vậy, bạn nên thay đổi mã của mình thành:
INSERT INTO table (this, that) VALUES ('$this', '$that')
nhắc nhở rằng `` được sử dụng để xác định các trường, cơ sở dữ liệu hoặc bảng MySQL, không phải giá trị;)
Mất kết nối với máy chủ trong khi truy vấn:
http://dev.mysql.com/doc/refman /5.1/en/gone-away.html
http://dev.mysql.com/doc /refman/5.1/en/packet-too-large.html
http://dev.mysql.com/doc/refman /5.0/en/server-parameters.html
http://dev.mysql.com/doc/refman /5.1/en/show-variables.html
http://dev.mysql.com/doc/refman /5.1/en/option-files.html
http://dev.mysql.com/doc/refman /5.1/en/error-log.html
Truy vấn điều chỉnh
http://www.artfulsoftware.com/infotree/queries.php?&bw =1313
Chà, thế là đủ để kiếm được tiền thưởng mà tôi nghĩ ... Thành quả của nhiều giờ và nhiều dự án với một miễn phí tuyệt vời cơ sở dữ liệu. Tôi phát triển máy chủ dữ liệu ứng dụng trên nền tảng windows chủ yếu bằng MySQL. Vấn đề tồi tệ nhất mà tôi phải giải quyết là
Cơn ác mộng cơ sở dữ liệu kế thừa MySQL cuối cùng
Điều này đòi hỏi một loạt ứng dụng để xử lý các bảng thành một thứ gì đó hữu ích bằng cách sử dụng nhiều thủ thuật được đề cập ở đây.
Nếu bạn thấy điều này hữu ích một cách đáng kinh ngạc, hãy bày tỏ sự cảm ơn của bạn bằng cách bỏ phiếu cho nó.
Ngoài ra, hãy xem các bài báo và sách trắng khác của tôi tại:www.coastrd.com
