對(duì)MySQL配置參數(shù) my.ini/my.cnf的詳細(xì)解析
更新時(shí)間：2010年08月08日 16:26:01 作者：
今天我們今天主要向大家描述的是MySQL配置參數(shù) my.ini/my.cnf，以下的文章就是對(duì)其實(shí)際操作的具體內(nèi)容的詳細(xì)解析
以下的文章主要描述的是對(duì)MySQL配置參數(shù) my.ini/my.cnf的詳細(xì)解析，我們主要是以實(shí)例演示的方式來(lái)對(duì)MySQL配置參數(shù) my.ini/my.cnf的實(shí)際操作步驟進(jìn)行說(shuō)明，以下就是相關(guān)內(nèi)容的具體描述。
1．獲取當(dāng)前配置參數(shù)
要優(yōu)化MySQL配置參數(shù)，首先要了解當(dāng)前的配置參數(shù)以及運(yùn)行情況。使用下列命令可以獲得目前服務(wù)器使用的配置參數(shù)：
mysqld –verbose –help
mysqladmin variables extended-status –u root –p
在MySQL控制臺(tái)里面，運(yùn)行下列命令可以獲取狀態(tài)變量的值：
mysql> SHOW STATUS; 如果只要檢查某幾個(gè)狀態(tài)變量，可以使用下列命令：
mysql> SHOW STATUS LIKE ‘[匹配模式]'; ( 可以使用%、?等 )
2．優(yōu)化參數(shù)
參數(shù)優(yōu)化基于一個(gè)前提，就是在我們的數(shù)據(jù)庫(kù)中通常都使用InnoDB表，而不使用MyISAM表。在優(yōu)化MySQL時(shí)，有兩個(gè)MySQL配置參數(shù)是最重要的，即table_cache和key_buffer_size。
table_cache
table_cache指定表高速緩存的大小。每當(dāng)MySQL訪問(wèn)一個(gè)表時(shí)，如果在表緩沖區(qū) 中還有空間，該表就被打開(kāi)并放入其中，這樣可以更快地訪問(wèn)表內(nèi)容。通過(guò)檢查峰值時(shí)間的狀態(tài)值Open_tables和Opened_tables，可以決 定是否需要增加table_cache的值。如果你發(fā)現(xiàn) open_tables等于table_cache，并且opened_tables在不斷增長(zhǎng)，那么你就需要增加table_cache的值了（上述狀 態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables'獲得）。注意，不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高，可能會(huì)造成文件描述符不足，從而造成性能 不穩(wěn)定或者連接失敗。
對(duì)于有1G內(nèi)存的機(jī)器，推薦值是128－256。
案例1：該案例來(lái)自一個(gè)不是特別繁忙的服務(wù)器
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
該案例中table_cache似乎設(shè)置得太高了。在峰值時(shí)間，打開(kāi)表的數(shù)目比table_cache要少得多。
案例2：該案例來(lái)自一臺(tái)開(kāi)發(fā)服務(wù)器。
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
雖然open_tables已經(jīng)等于table_cache，但是相對(duì)于服務(wù)器運(yùn)行時(shí)間來(lái)說(shuō)，opened_tables的值也非常低。因此，增加table_cache的值應(yīng)該用處不大。
案例3：該案例來(lái)自一個(gè)upderperforming的服務(wù)器
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
該案例中table_cache設(shè)置得太低了。雖然運(yùn)行時(shí)間不到6小時(shí)，open_tables達(dá)到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。
key_buffer_size
key_buffer_size指定索引緩沖區(qū)的大小，它決定索引處理的速度，尤其是索引讀 的速度。通過(guò)檢查狀態(tài)值 Key_read_requests和Key_reads，可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%'獲得）。
key_buffer_size只對(duì)MyISAM表起作用。即使你不使用MyISAM表，但是內(nèi)部的臨時(shí)磁盤表是MyISAM表，也要使用該值?？梢允褂脵z查狀態(tài)值created_tmp_disk_tables得知詳情。
對(duì)于1G內(nèi)存的機(jī)器，如果不使用MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況
key_buffer_size – 402649088 (384M)
key_read_requests – 597579931
key_reads – 56188
案例2：警報(bào)狀態(tài)
key_buffer_size – 16777216 (16M)
key_read_requests – 597579931
key_reads – 53832731
案例1中比例低于1:10000，是健康的情況；案例2中比例達(dá)到1:11，警報(bào)已經(jīng)拉響。
優(yōu)化query_cache_size
從4.0.1開(kāi)始，MySQL配置參數(shù)提供了查詢緩沖機(jī)制。使用查詢緩沖，MySQL將SELECT語(yǔ)句和查詢結(jié)果存放在緩沖區(qū)中，今后對(duì)于同樣的SELECT語(yǔ)句（區(qū)分大小寫），將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊(cè)，使用查詢緩沖最多可以達(dá)到238％的效率。
通過(guò)檢查狀態(tài)值Qcache_*，可以知道query_cache_size設(shè)置是否合理 （上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Qcache%'獲得）。如果Qcache_lowmem_prunes的值非常大，則表明經(jīng)常出現(xiàn)緩沖不夠的情況，如果Qcache_hits的值也 非常大，則表明查詢緩沖使用非常頻繁，此時(shí)需要增加緩沖大?。?
如果Qcache_hits的值不大，則表明你的查詢重復(fù)率很低，這種情況下使用查詢緩沖反 而會(huì)影響效率，那么可以考慮不用查詢緩沖。此外，在SELECT語(yǔ)句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
與查詢緩沖有關(guān)的參數(shù)還有query_cache_type、 query_cache_limit、 query_cache_min_res_unit。query_cache_type指定是否使用查詢緩沖，可以設(shè)置為0、1、2，該變量是 SESSION級(jí)的變量。
query_cache_limit指定單個(gè)查詢能夠使用的緩沖區(qū)大小，缺省為1M。 query_cache_min_res_unit是在4.1版本以后引入的，它指定分配緩沖區(qū)空間的最小單位，缺省為4K。檢查狀態(tài)值 Qcache_free_blocks，如果該值非常大，則表明緩沖區(qū)中碎片很多，這就表明查詢結(jié)果都比較小，此時(shí)需要減小 query_cache_min_res_unit。
開(kāi)啟二進(jìn)制日志( Binary Log )
二進(jìn)制日志包含所有更新數(shù)據(jù)的語(yǔ)句，其目的是在恢復(fù)數(shù)據(jù)庫(kù)時(shí)用它來(lái)把數(shù)據(jù)盡可能恢復(fù)到最后的狀態(tài)。另外，如果做同步復(fù)制( Replication )的話，也需要使用二進(jìn)制日志傳送修改情況。
開(kāi)啟二進(jìn)制日志，需要設(shè)置參數(shù)log-bin。log_bin指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。MySQL會(huì)在文件名后面自動(dòng)添加數(shù)字索引，每次啟動(dòng)服務(wù)時(shí)，都會(huì)重新生成一個(gè)新的二進(jìn)制文件。
此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以 指定記錄的數(shù)據(jù)庫(kù)；使用binlog-ignore- db可以指定不記錄的數(shù)據(jù)庫(kù)。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個(gè)數(shù)據(jù)庫(kù)，指定多個(gè)數(shù)據(jù)庫(kù)需要多個(gè)語(yǔ) 句。而且，MySQL會(huì)將所有的數(shù)據(jù)庫(kù)名稱改成小寫，在指定數(shù)據(jù)庫(kù)時(shí)必須全部使用小寫名字，否則不會(huì)起作用。
在MySQL中使用SHOW MASTER STATUS命令可以查看目前的二進(jìn)制日志狀態(tài)。
開(kāi)啟慢查詢?nèi)罩? slow query log )
慢查詢?nèi)罩緦?duì)于跟蹤有問(wèn)題的查詢非常有用。它記錄所有查過(guò)long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個(gè)慢查詢?nèi)罩镜睦樱?
開(kāi)啟慢查詢?nèi)罩?，需要設(shè)置參數(shù)log_slow_queries、 long_query_times、log-queries-not-using -indexes。log_slow_queries指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。 long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的 參數(shù)，它指示記錄不使用索引的查詢。
配置InnoDB
相對(duì)于MyISAM表來(lái)說(shuō)，正確MySQL配置參數(shù)對(duì)于InnoDB表更加關(guān)鍵。其中，最重要的參數(shù)是 innodb_data_file_path。它指定表數(shù)據(jù)和索引存儲(chǔ)的空間，可以是一個(gè)或者多個(gè)文件。最后一個(gè)數(shù)據(jù)文件必須是自動(dòng)擴(kuò)充的，也只有最后一 個(gè)文件允許自動(dòng)擴(kuò)充。這樣，當(dāng)空間用完后，自動(dòng)擴(kuò)充數(shù)據(jù)文件就會(huì)自動(dòng)增長(zhǎng)（以8MB為單位）以容納額外的數(shù)據(jù)。例如：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend
兩個(gè)數(shù)據(jù)文件放在不同的磁盤上。數(shù)據(jù)首先放在ibdata1中，當(dāng)達(dá)到900M以后，數(shù)據(jù)就放在ibdata2中。一旦達(dá)到50MB，ibdata2將以8MB為單位自動(dòng)增長(zhǎng)。
如果磁盤滿了，你需要在另外的磁盤上面增加一個(gè)數(shù)據(jù)文件。為此，你需要查看最后一個(gè)文件的尺寸，然后計(jì)算最接近的整數(shù)（MB）。然后手工修改該文件的大小，并添加新的數(shù)據(jù)文件。例如：假設(shè)ibdata2已經(jīng)有109MB數(shù)據(jù)，那么可以修改如下：
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:109M;/disk3/ibdata3:500M:autoextend
flush_time
如果系統(tǒng)有問(wèn)題并且經(jīng)常鎖死或重新引導(dǎo)，應(yīng)將該變量設(shè)置為非零值，這將導(dǎo)致服務(wù)器按flush_time 秒來(lái)刷新表的高速緩存。用這種方法來(lái)寫出對(duì)表的修改將降低性能，但可減少表訛誤或數(shù)據(jù)丟失的機(jī)會(huì)。
1．獲取當(dāng)前配置參數(shù)
要優(yōu)化MySQL配置參數(shù)，首先要了解當(dāng)前的配置參數(shù)以及運(yùn)行情況。使用下列命令可以獲得目前服務(wù)器使用的配置參數(shù)：
復(fù)制代碼 代碼如下:
mysqld –verbose –help
mysqladmin variables extended-status –u root –p
在MySQL控制臺(tái)里面，運(yùn)行下列命令可以獲取狀態(tài)變量的值：
復(fù)制代碼 代碼如下:
mysql> SHOW STATUS; 如果只要檢查某幾個(gè)狀態(tài)變量，可以使用下列命令：
mysql> SHOW STATUS LIKE ‘[匹配模式]'; ( 可以使用%、?等 )
2．優(yōu)化參數(shù)
參數(shù)優(yōu)化基于一個(gè)前提，就是在我們的數(shù)據(jù)庫(kù)中通常都使用InnoDB表，而不使用MyISAM表。在優(yōu)化MySQL時(shí)，有兩個(gè)MySQL配置參數(shù)是最重要的，即table_cache和key_buffer_size。
table_cache
table_cache指定表高速緩存的大小。每當(dāng)MySQL訪問(wèn)一個(gè)表時(shí)，如果在表緩沖區(qū) 中還有空間，該表就被打開(kāi)并放入其中，這樣可以更快地訪問(wèn)表內(nèi)容。通過(guò)檢查峰值時(shí)間的狀態(tài)值Open_tables和Opened_tables，可以決 定是否需要增加table_cache的值。如果你發(fā)現(xiàn) open_tables等于table_cache，并且opened_tables在不斷增長(zhǎng)，那么你就需要增加table_cache的值了（上述狀 態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables'獲得）。注意，不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高，可能會(huì)造成文件描述符不足，從而造成性能 不穩(wěn)定或者連接失敗。
對(duì)于有1G內(nèi)存的機(jī)器，推薦值是128－256。
案例1：該案例來(lái)自一個(gè)不是特別繁忙的服務(wù)器
復(fù)制代碼 代碼如下:
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
該案例中table_cache似乎設(shè)置得太高了。在峰值時(shí)間，打開(kāi)表的數(shù)目比table_cache要少得多。
案例2：該案例來(lái)自一臺(tái)開(kāi)發(fā)服務(wù)器。
復(fù)制代碼 代碼如下:
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
雖然open_tables已經(jīng)等于table_cache，但是相對(duì)于服務(wù)器運(yùn)行時(shí)間來(lái)說(shuō)，opened_tables的值也非常低。因此，增加table_cache的值應(yīng)該用處不大。
案例3：該案例來(lái)自一個(gè)upderperforming的服務(wù)器
復(fù)制代碼 代碼如下:
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
該案例中table_cache設(shè)置得太低了。雖然運(yùn)行時(shí)間不到6小時(shí)，open_tables達(dá)到了最大值，opened_tables的值也非常高。這樣就需要增加table_cache的值。
key_buffer_size
key_buffer_size指定索引緩沖區(qū)的大小，它決定索引處理的速度，尤其是索引讀 的速度。通過(guò)檢查狀態(tài)值 Key_read_requests和Key_reads，可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好（上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%'獲得）。
key_buffer_size只對(duì)MyISAM表起作用。即使你不使用MyISAM表，但是內(nèi)部的臨時(shí)磁盤表是MyISAM表，也要使用該值?？梢允褂脵z查狀態(tài)值created_tmp_disk_tables得知詳情。
對(duì)于1G內(nèi)存的機(jī)器，如果不使用MyISAM表，推薦值是16M（8-64M）。
案例1：健康狀況
復(fù)制代碼 代碼如下:
key_buffer_size – 402649088 (384M)
key_read_requests – 597579931
key_reads – 56188
案例2：警報(bào)狀態(tài)
復(fù)制代碼 代碼如下:
key_buffer_size – 16777216 (16M)
key_read_requests – 597579931
key_reads – 53832731
案例1中比例低于1:10000，是健康的情況；案例2中比例達(dá)到1:11，警報(bào)已經(jīng)拉響。
優(yōu)化query_cache_size
從4.0.1開(kāi)始，MySQL配置參數(shù)提供了查詢緩沖機(jī)制。使用查詢緩沖，MySQL將SELECT語(yǔ)句和查詢結(jié)果存放在緩沖區(qū)中，今后對(duì)于同樣的SELECT語(yǔ)句（區(qū)分大小寫），將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊(cè)，使用查詢緩沖最多可以達(dá)到238％的效率。
通過(guò)檢查狀態(tài)值Qcache_*，可以知道query_cache_size設(shè)置是否合理 （上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Qcache%'獲得）。如果Qcache_lowmem_prunes的值非常大，則表明經(jīng)常出現(xiàn)緩沖不夠的情況，如果Qcache_hits的值也 非常大，則表明查詢緩沖使用非常頻繁，此時(shí)需要增加緩沖大?。?
如果Qcache_hits的值不大，則表明你的查詢重復(fù)率很低，這種情況下使用查詢緩沖反 而會(huì)影響效率，那么可以考慮不用查詢緩沖。此外，在SELECT語(yǔ)句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
與查詢緩沖有關(guān)的參數(shù)還有query_cache_type、 query_cache_limit、 query_cache_min_res_unit。query_cache_type指定是否使用查詢緩沖，可以設(shè)置為0、1、2，該變量是 SESSION級(jí)的變量。
query_cache_limit指定單個(gè)查詢能夠使用的緩沖區(qū)大小，缺省為1M。 query_cache_min_res_unit是在4.1版本以后引入的，它指定分配緩沖區(qū)空間的最小單位，缺省為4K。檢查狀態(tài)值 Qcache_free_blocks，如果該值非常大，則表明緩沖區(qū)中碎片很多，這就表明查詢結(jié)果都比較小，此時(shí)需要減小 query_cache_min_res_unit。
開(kāi)啟二進(jìn)制日志( Binary Log )
二進(jìn)制日志包含所有更新數(shù)據(jù)的語(yǔ)句，其目的是在恢復(fù)數(shù)據(jù)庫(kù)時(shí)用它來(lái)把數(shù)據(jù)盡可能恢復(fù)到最后的狀態(tài)。另外，如果做同步復(fù)制( Replication )的話，也需要使用二進(jìn)制日志傳送修改情況。
開(kāi)啟二進(jìn)制日志，需要設(shè)置參數(shù)log-bin。log_bin指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。MySQL會(huì)在文件名后面自動(dòng)添加數(shù)字索引，每次啟動(dòng)服務(wù)時(shí)，都會(huì)重新生成一個(gè)新的二進(jìn)制文件。
此外，使用log-bin-index可以指定索引文件；使用binlog-do-db可以 指定記錄的數(shù)據(jù)庫(kù)；使用binlog-ignore- db可以指定不記錄的數(shù)據(jù)庫(kù)。注意的是：binlog-do-db和binlog-ignore-db一次只指定一個(gè)數(shù)據(jù)庫(kù)，指定多個(gè)數(shù)據(jù)庫(kù)需要多個(gè)語(yǔ) 句。而且，MySQL會(huì)將所有的數(shù)據(jù)庫(kù)名稱改成小寫，在指定數(shù)據(jù)庫(kù)時(shí)必須全部使用小寫名字，否則不會(huì)起作用。
在MySQL中使用SHOW MASTER STATUS命令可以查看目前的二進(jìn)制日志狀態(tài)。
開(kāi)啟慢查詢?nèi)罩? slow query log )
慢查詢?nèi)罩緦?duì)于跟蹤有問(wèn)題的查詢非常有用。它記錄所有查過(guò)long_query_time的查詢，如果需要，還可以記錄不使用索引的記錄。下面是一個(gè)慢查詢?nèi)罩镜睦樱?
開(kāi)啟慢查詢?nèi)罩?，需要設(shè)置參數(shù)log_slow_queries、 long_query_times、log-queries-not-using -indexes。log_slow_queries指定日志文件，如果不提供文件名，MySQL將自己產(chǎn)生缺省文件名。 long_query_times指定慢查詢的閾值，缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的 參數(shù)，它指示記錄不使用索引的查詢。
配置InnoDB
相對(duì)于MyISAM表來(lái)說(shuō)，正確MySQL配置參數(shù)對(duì)于InnoDB表更加關(guān)鍵。其中，最重要的參數(shù)是 innodb_data_file_path。它指定表數(shù)據(jù)和索引存儲(chǔ)的空間，可以是一個(gè)或者多個(gè)文件。最后一個(gè)數(shù)據(jù)文件必須是自動(dòng)擴(kuò)充的，也只有最后一 個(gè)文件允許自動(dòng)擴(kuò)充。這樣，當(dāng)空間用完后，自動(dòng)擴(kuò)充數(shù)據(jù)文件就會(huì)自動(dòng)增長(zhǎng)（以8MB為單位）以容納額外的數(shù)據(jù)。例如：
復(fù)制代碼 代碼如下:
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:50M:autoextend
兩個(gè)數(shù)據(jù)文件放在不同的磁盤上。數(shù)據(jù)首先放在ibdata1中，當(dāng)達(dá)到900M以后，數(shù)據(jù)就放在ibdata2中。一旦達(dá)到50MB，ibdata2將以8MB為單位自動(dòng)增長(zhǎng)。
如果磁盤滿了，你需要在另外的磁盤上面增加一個(gè)數(shù)據(jù)文件。為此，你需要查看最后一個(gè)文件的尺寸，然后計(jì)算最接近的整數(shù)（MB）。然后手工修改該文件的大小，并添加新的數(shù)據(jù)文件。例如：假設(shè)ibdata2已經(jīng)有109MB數(shù)據(jù)，那么可以修改如下：
復(fù)制代碼 代碼如下:
innodb_data_file_path=/disk1/ibdata1:900M;/disk2/ibdata2:109M;/disk3/ibdata3:500M:autoextend
flush_time
如果系統(tǒng)有問(wèn)題并且經(jīng)常鎖死或重新引導(dǎo)，應(yīng)將該變量設(shè)置為非零值，這將導(dǎo)致服務(wù)器按flush_time 秒來(lái)刷新表的高速緩存。用這種方法來(lái)寫出對(duì)表的修改將降低性能，但可減少表訛誤或數(shù)據(jù)丟失的機(jī)會(huì)。
相關(guān)文章
索引并不是時(shí)時(shí)都會(huì)生效的,在一起情況下將導(dǎo)致索引失效,這篇文章主要給大家介紹了關(guān)于MySQL索引失效的幾種情況,文章通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2023-06-06
MySQL中distinct與group by之間的性能進(jìn)行比較
這篇文章主要針對(duì)MySQL中distinct與group by之間的性能進(jìn)行比較，內(nèi)容比較詳細(xì)，很直觀的能看出比較結(jié)果，感興趣的小伙伴們可以參考一下2015-11-11
這篇文章主要給大家介紹了關(guān)于MySQL普通索引和唯一索引的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-01-01
在高并發(fā)的場(chǎng)景下,大量的請(qǐng)求直接訪問(wèn)Mysql很容易造成性能問(wèn)題,下面這篇文章主要給大家介紹了關(guān)于MySQL如何保證備份數(shù)據(jù)一致性的相關(guān)資料,文中通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2022-05-05
Mysql和其它開(kāi)源數(shù)據(jù)庫(kù)相比，具有更好的擴(kuò)展性。其主要原因是它提供了存儲(chǔ)引擎的開(kāi)放接口。喜歡自己折騰數(shù)據(jù)庫(kù)的程序員可以從這個(gè)接口起步，打造有個(gè)性的數(shù)據(jù)庫(kù)。2011-07-07
當(dāng)面試官問(wèn)mysql中char與varchar的區(qū)別
這篇文章主要以聊天形式圖片的添加，將面試官面試真實(shí)場(chǎng)景體現(xiàn)出來(lái)，好奇的朋友不要錯(cuò)過(guò)奧2021-08-08
MySQL?8.0引入的窗口函數(shù),增強(qiáng)了數(shù)據(jù)分析能力,窗口函數(shù)允許對(duì)數(shù)據(jù)集（窗口）進(jìn)行操作,與GROUPBY類似,但每個(gè)查詢行生成獨(dú)立結(jié)果,包括聚合函數(shù)如SUM、AVG,專用窗口函數(shù)如ROW_NUMBER等,窗口函數(shù)應(yīng)用于數(shù)據(jù)分組、排序、排名,并支持復(fù)雜分析場(chǎng)景,需要的朋友可以參考下2024-11-11
mySQL count多個(gè)表的數(shù)據(jù)實(shí)例詳解
這篇文章通過(guò)實(shí)例給大家介紹了mySQL中count多個(gè)表的數(shù)據(jù)，也就是多個(gè)表如何聯(lián)合查詢，文中通過(guò)項(xiàng)目中遇到的一個(gè)問(wèn)題進(jìn)行分析和實(shí)現(xiàn)，給出了詳細(xì)的示例代碼，相信對(duì)大家的理解和學(xué)習(xí)很有幫助，有需要的朋友們下面來(lái)一起看看吧。2016-11-11
mysql數(shù)據(jù)庫(kù)row_number函數(shù)舉例介紹
在MySQL中ROW_NUMBER()是一種用來(lái)生成行號(hào)的功能函數(shù),通常情況下它用于對(duì)查詢結(jié)果進(jìn)行編號(hào),以便方便地查看每行的位置,下面這篇文章主要給大家介紹了關(guān)于mysql數(shù)據(jù)庫(kù)row_number函數(shù)舉例介紹的相關(guān)資料,需要的朋友可以參考下2024-02-02
本章列出了當(dāng)你用任何主機(jī)語(yǔ)言調(diào)用MySQL時(shí)可能出現(xiàn)的錯(cuò)誤。首先列出了服務(wù)器錯(cuò)誤消息。其次列出了客戶端程序消息2014-01-01