服務器mysql多大(服務器配置mysql)

本文目錄一覽:

MySQL服務器數量大嗎

不算太大。

MySQL3.22限制的表大小為4GB。由於在MySQL3.23中使用了MyISAM存儲引擎,最大表尺寸增加到了65536TB2567至1位元組。由於允許的表尺寸更大,MySQL數據庫的最大有效表尺寸通常是由操作系統對文件大小的限制決定的,而不是由MySQL內部限制決定的。

MySQL是中小型網站普遍使用的數據庫之一,然而很多人並不清楚MySQL到底能支持多大的數據量,再加上某些國內CMS廠商把數據承載量的責任推給它,導致很多不了解MySQL的站長對它產生了很多誤解。

優化mysql 多大內存 centos6

一、mysql的優化思路

mysql的優化分為兩方面:

1. 服務器使用前的優化

2. 服務使用中的優化

二、mysql的基礎優化步驟

1. 硬件級優化

(1). 最好mysql自己使用一台物理服務器

(2). 內存和CPU方面,根據需求給予mysql服務器足夠大的內存和足夠多的CPU核數

(3). 避免使用Swap交換分區–交換時從硬盤讀取的它的速度很慢,有的DBA安裝系統時就不裝swap分區

(4). 如果是mysql主庫,硬盤可以選用比較好的高速硬盤,系統用SSD固態硬盤,數據盤用sas替代sata硬盤,將操作系統和數據分區分開

(5). mysql產生的日誌與數據庫也放到不同的磁盤分區上面

(6). mysql數據庫硬盤格式化時,可以指定更小的硬盤塊

(7). 關於做RAID方面,主庫盡量做成RAID10,既提高了數據的讀寫速度也提到了數據的安全性

(8). 服務器雙線雙電,保障服務器運行穩定,不會因為突然斷電影響業務和損壞磁盤數據

2. mysql數據庫設計優化

(1). 根據需求選擇正確的存儲引擎,比如說讀的特別猛就用MySAM,如果對事務性要求高就用InnoDB

(2). 設置合理的字段類型和字段長度,比如說你這個字段就20多個字段你設置成VARCHAR(255)就是對磁盤空間的浪費

(3). 默認值儘可能的使用 NOT NULL,如果空值太多對mysql的查詢會有影響,尤其是在查詢語句編寫上面

(4). 盡量少的使用VARCHAR,TEXT,BLOB這三個字段

(5). 添加適當索引(index) [四種: 普通索引、主鍵索引、唯一索引unique、全文索引]

(6). 不要濫用索引,大表索引,小表不索引

(7). 表的設計合理化(符合3NF)

3. mysql配置參數的優化

這裡是mysql5.5版本的配置文件

vi my.cnf

[client]

port = 3306 #mysql客戶端連接時的默認端口

socket = /tmp/mysql.sock #與mysql服務器本地通信所使用的socket文件路徑

default-character-set = utf8 #指定默認字符集為utf8

[mysql]

no-auto-rehash #auto-rehash是自動補全的意思,就像我們在linux命令行里輸入命令的時候,使用tab鍵的功能是一樣的,這裡是默認的不自動補全

default-character-set = utf8 #指定默認字符集為utf8

[mysqld]

user = mysql

port = 3306

character-set-server = utf8 #設置服務器端的字符編碼

socket = /tmp/mysql.sock

basedir = /application/mysql

datadir = /mysqldata

skip-locking #避免MySQL的外部鎖定,減少出錯幾率增強穩定性。

open_files_limit = 10240 #MySQL打開的文件描述符限制,默認最小1024;當open_files_limit沒有被配置的時候,比較max_connections*5和ulimit -n的值,哪個大用哪個,當open_file_limit被配置的時候,比較open_files_limit和max_connections*5的值,哪個大用哪個。

back_log = 500 #back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可 以被存在堆棧中。 如果系統在一個短時間內有很多連接,則需要增大該參數的值,該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。

max_connections = 800 #MySQL的最大連接數,如果服務器的並發連接請求量比較大,建議調高此值,以增加並行連接數量,當然這建立在機器能支撐的情況下,因為如果連接數越多, 介於MySQL會為每個連接提供連接緩衝區,就會開銷越多的內存,所以要適當調整該值,不能盲目提高設值。可以過』conn%』通配符查看當前狀態的連接 數量,以定奪該值的大小。

max_connect_errors = 3000 #對於同一主機,如果有超出該參數值個數的中斷錯誤連接,則該主機將被禁止連接。如需對該主機進行解禁,執行:FLUSH HOST。

table_cache = 614 #物理內存越大,設置就越大.默認為2402,調到512-1024最佳

external-locking = FALSE #使用–skip-external-locking MySQL選項以避免外部鎖定。該選項默認開啟

max_allowed_packet =8M #設置最大包,限制server接受的數據包大小,避免超長SQL的執行有問題 默認值為16M,當MySQL客戶端或mysqld服務器收到大於max_allowed_packet位元組的信息包時,將發出「信息包過大」錯誤,並關閉連接。對於某些客戶端,如果通信信息包過大,在執行查詢期間,可能會遇「丟失與MySQL服務器的連接」錯誤。默認值16M。

sort_buffer_size = 6M #用於表間關聯緩存的大小,查詢排序時所能使用的緩衝區大小。注意:該參數對應的分配內存是每連接獨佔,如果有100個連接,那麼實際分配的總共排序緩衝區大小為100 × 6 = 600MB。所以,對於內存在4GB左右的服務器推薦設置為6-8M。

join_buffer_size = 6M #聯合查詢操作所能使用的緩衝區大小,和sort_buffer_size一樣,該參數對應的分配內存也是每連接獨享。

thread_cache_size = 100 #服務器線程緩存這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那麼客戶端的線程將被放到緩存中,如果線程重新被請求, 那麼請求將從緩存中讀取,如果緩存中是空的或者是新的請求,那麼這個線程將被重新創建,如果有很多新的線程,增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變量,可以看到這個變量的作用

thread_concurrency = 8 #設置thread_concurrency的值的正確與否, 對mysql的性能影響很大, 在多個cpu(或多核)的情況下,錯誤設置了thread_concurrency的值, 會導致mysql不能充分利用多cpu(或多核), 出現同一時刻只能一個cpu(或核)在工作的情況。thread_concurrency應設為CPU核數的2倍. 比如有一個雙核的CPU, 那麼thread_concurrency的應該為4; 2個雙核的cpu, thread_concurrency的值應為8,屬重點優化參數

query_cache_size = 2M #指定MySQL查詢緩衝區的大小,在數據庫寫入量或是更新量也比較大的系統,該參數不適合分配過大。而且在高並發,寫入量大的系統,建系把該功能禁掉。

query_cache_limit = 1M #默認是4KB,設置值大對大數據查詢有好處,但如果你的查詢都是小數據查詢,就容易造成內存碎片和浪費

query_cache_min_res_unit = 2k #MySQL參數中query_cache_min_res_unit查詢緩存中的塊是以這個大小進行分配的,使用下面的公式計算查詢緩存的平均大小,根據計算結果設置這個變量,MySQL就會更有效地使用查詢緩存,緩存更多的查詢,減少內存的浪費。

default_table_type = InnoDB #默認表的引擎為InnoDB

thread_stack = 192K #限定用於每個數據庫線程的棧大小。默認設置足以滿足大多數應用transaction_isolation = READ-COMMITTED #設定默認的事務隔離級別.可用的級別如下:

READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE,1.READ UNCOMMITTED-讀未提交2.READ COMMITTE-讀已提交3.REPEATABLE READ -可重複讀4.SERIALIZABLE -串行

tmp_table_size = 246M #tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小,MySQL產生一個 The table tbl_name is full 形式的錯誤,如果你做很多高級 GROUP BY 查詢,增加 tmp_table_size 值。

max_heap_table_size = 246M #內存表,內存表不支持事務,內存表使用哈希散列索引把數據保存在內存中,因此具有極快的速度,適合緩存中小型數據庫,但是使用上受到一些限制

long_query_time = 1 #記錄時間超過1秒的查詢語句

log_long_format #

log-error = /logs/error.log #開啟mysql錯誤日誌,該選項指定mysqld保存錯誤日誌文件的位置

log-slow-queries = /logs/slow.log #慢查詢日誌文件路徑

pid-file = /pids/mysql.pid

log-bin = /binlog/mysql-bin #binlog日誌位置以及binlog的名稱

relay-log = /relaylog/relay-bin #relaylog日誌位置以名稱

binlog_cache_size = 1M #binlog_cache_size 就是滿足兩點的:一個事務,在沒有提交(uncommitted)的時候,產生的日誌,記錄到Cache中;等到事務提交(committed)需要提交的時候,則把日誌持久化到磁盤,默認是32K。

max_binlog_cache_size = 32M #binlog緩存最大使用的內存

max_binlog_size = 2M #一個binlog日誌的大小

expire_logs_days = 7 #保留7天的binlog

key_buffer_size = 124M #索引緩存大小: 它決定了數據庫索引處理的速度,尤其是索引讀的速度

read_buffer_size = 16M #MySql讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區,MySql會為它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。如果對錶的順序掃描請求非常頻繁,並且你認為頻繁掃描進行得太慢,可以通過增加該變量值以及內存緩衝區大小提高其性能

read_rnd_buffer_size = 2M #MySQL的隨機讀緩衝區大小。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。進行排序查詢時,MySQL會首先掃描一遍該緩衝,以避免磁盤搜索,提高查詢速度,如果需要排序大量數據,可適當調高該值。但MySQL會為每個客戶連接發放該緩衝空間,所以應盡量適當設置該值,以避免內存開銷過大

bulk_insert_buffer_size = 1M #批量插入數據緩存大小,可以有效提高插入效率,默認為8M

myisam_sort_buffer_size = 1M #MyISAM表發生變化時重新排序所需的緩衝

myisam_max_sort_file_size = 10G #MySQL重建索引時所允許的最大臨時文件的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). 如果文件大小比此值更大,索引會通過鍵值緩衝創建(更慢)

myisam_repair_threads = 1 #如果一個表擁有超過一個索引, MyISAM 可以通過並行排序使用超過一個線程去修復他們.這對於擁有多個CPU以及大量內存情況的用戶,是一個很好的選擇.

myisam_recover #自動檢查和修復沒有適當關閉的 MyISAM 表

lower_case_table_names = 1 #讓mysql不區分大小寫

skip-name-resolve #禁用DNS解析,連接速度會快很多。不過,這樣的話就不能在MySQL的授權表中使用主機名了而只能用ip格式。

#slave-skip-errors = 1032,1062 #這是選填項讓slave庫跳過哪些錯誤繼續同步

#replicate-ignore-db=mysql #選填,同步時候哪個數據庫不同步設置

server-id = 1

innodb_additional_mem_pool_size = 4M #InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小。應用程序里的表越多,你需要在這裡分配越多的內存,默認是2M

innodb_buffer_pool_size = 2048M #這對Innodb表來說非常重要。Innodb相比MyISAM表對緩衝更為敏感。MyISAM可以在默 認的 key_buffer_size 設置下運行的可以,然而Innodb在默認的 設置下卻跟蝸牛似的。由於Innodb把數據和索引都緩存起來,無需留給操作系統太多的內存,因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 如果你的數據量不大,並且不會暴增,那麼無需把 innodb_buffer_pool_size 設置的太大了

innodb_file_io_threads = 4 #文件IO的線程數,一般為 4

innodb_thread_concurrency = 8 #你的服務器CPU有幾個就設置為幾,建議用默認一般為8

innodb_flush_log_at_trx_commit = 2 #默認為1,如果將此參數設置為1,將在每次提交事務後將日誌寫入磁盤。為提供性能,可以設置為0或2,但要承擔在發生故障時丟失數據的風險。設置為0表示事務日誌寫入日誌文件,而日誌文件每秒刷新到磁盤一次。設置為2表示事務日誌將在提交時寫入日誌,但日誌文件每次刷新到磁盤一次。

innodb_log_buffer_size = 2M #此參數確定些日誌文件所用的內存大小,以M為單位。緩衝區更大能提高性能,但意外的故障將會丟失數據.MySQL開發人員建議設置為1-8M之間

innodb_log_file_size = 4M #此參數確定數據日誌文件的大小,以M為單位,更大的設置可以提高性能,但也會增加恢復故障數據庫所需的時間

innodb_log_files_in_group = 3 #為提高性能,MySQL可以以循環方式將日誌文件寫到多個文件。推薦設置為3M

innodb_max_dirty_pages_pct = 90 #Buffer_Pool中Dirty_Page所佔的數量,直接影響InnoDB的關閉時間。參數 innodb_max_dirty_pages_pct可以直接控制了Dirty_Page在Buffer_Pool中所佔的比率,而且幸運的是 innodb_max_dirty_pages_pct是可以動態改變的。所以,在關閉InnoDB之前先調小,強制數據塊Flush一段時間,則能夠大大縮短MySQL關閉的時間。

innodb_lock_wait_timeout = 120 #InnoDB 有其內置的死鎖檢測機制,能導致未完成的事務回滾。但是,如果結合InnoDB使用MyISAM的lock tables 語句或第三方事務引擎,則InnoDB無法識別死鎖。為消除這種可能性,可以將innodb_lock_wait_timeout設置為一個整數值,指示 MySQL在允許其他事務修改那些最終受事務回滾的數據之前要等待多長時間(秒數)

innodb_file_per_table = 0 #獨享表空間(關閉)

[mysqldump]

quick

max_allowed_packet = 16M

4. 架構優化

(1). 前端用memcached,redis等緩存分擔數據庫壓力

(2). 數據庫讀寫分離,負載均衡

(3). 數據庫分庫分表

(4). 存儲可採取分佈式

5. 後期優化

主要是多觀察,後期就是維護工作了,觀察服務器負載是需要添加硬件了,還是有語句有問題啊,還是參數要修改了。

6. 查詢優化(摘抄別人的)

63. 使用慢查詢日誌去發現慢查詢。

64. 使用執行計划去判斷查詢是否正常運行。

65. 總是去測試你的查詢看看是否他們運行在最佳狀態下 –久而久之性能總會變化。

66. 避免在整個表上使用count(*),它可能鎖住整張表。

67. 使查詢保持一致以便後續相似的查詢可以使用查詢緩存。

68. 在適當的情形下使用GROUP BY而不是DISTINCT。

69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。

70. 保持索引簡單,不在多個索引中包含同一個列。

71. 有時候MySQL會使用錯誤的索引,對於這種情況使用USE INDEX。

72. 檢查使用SQL_MODE=STRICT的問題。

73. 對於記錄數小於5的索引字段,在UNION的時候使用LIMIT不是是用OR.

74. 為了 避免在更新前SELECT,使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去實現。

75. 不要使用 MAX,使用索引字段和ORDER BY子句。

76. 避免使用ORDER BY RAND().

77。LIMIT M,N實際上可以減緩查詢在某些情況下,有節制地使用。

78。在WHERE子句中使用UNION代替子查詢。

79。對於UPDATES(更新),使用 SHARE MODE(共享模式),以防止獨佔鎖。

80。在重新啟動的MySQL,記得來溫暖你的數據庫,以確保您的數據在內存和查詢速度快。

81。使用DROP TABLE,CREATE TABLE DELETE FROM從表中刪除所有數據。

82。最小化的數據在查詢你需要的數據,使用*消耗大量的時間。

83。考慮持久連接,而不是多個連接,以減少開銷。

84。基準查詢,包括使用服務器上的負載,有時一個簡單的查詢可以影響其他查詢。

85。當負載增加您的服務器上,使用SHOW PROCESSLIST查看慢的和有問題的查詢。

86。在開發環境中產生的鏡像數據中 測試的所有可疑的查詢。

mysql數據庫服務器一般多少內存

我們仍然使用兩個會話,一個會話 run,用於運行主 SQL;另一個會話 ps,用於進行 performance_schema 的觀察:

主會話線程號為 29,

將 performance_schema 中的統計量重置,

臨時表的表大小限制取決於參數  tmp_table_size 和 max_heap_table_size 中較小者,我們實驗中以設置 max_heap_table_size 為例。

我們將會話級別的臨時表大小設置為 2M(小於上次實驗中臨時表使用的空間),執行使用臨時表的 SQL:

查看內存的分配記錄:

會發現內存分配略大於 2M,我們猜測臨時表會比配置略多一點消耗,可以忽略。

查看語句的特徵值:

可以看到語句使用了一次需要落磁盤的臨時表。

那麼這張臨時表用了多少的磁盤呢?

我們開啟 performance_schema 中 waits 相關的統計項:

重做實驗,略過。

再查看 performance_schema 的統計值:

可以看到幾個現象:

1. 臨時表空間被寫入了 7.92MiB 的數據。

2. 這些數據是語句寫入後,慢慢逐漸寫入的。

來看看這些寫入操作的特徵,該方法我們在 實驗 03 使用過:

可以看到寫入的線程是 page_clean_thread,是一個刷臟操作,這樣就能理解數據為什麼是慢慢寫入的。

也可以看到每個 IO 操作的大小是 16K,也就是刷數據頁的操作。

結論:

我們可以看到,

1. MySQL 會基本遵守 max_heap_table_size 的設定,在內存不夠用時,直接將錶轉到磁盤上存儲。

2. 由於引擎不同(內存中表引擎為 heap,磁盤中表引擎則跟隨 internal_tmp_disk_storage_engine 的配置),本次實驗寫磁盤的數據量和 實驗 05 中使用內存的數據量不同。

3. 如果臨時表要使用磁盤,表引擎配置為 InnoDB,那麼即使臨時表在一個時間很短的 SQL 中使用,且使用後即釋放,釋放後也會刷臟頁到磁盤中,消耗部分 IO。

mysql佔多少內存

MySQL 自身內存規劃

說到 MySQL 自身的內存規劃,最先想到的就是 MySQL 中各種 buffer 的大小,innodb buffer pool 就是最鶴立雞群的那個。innodb_buffer_pool_size 參數的大小究竟如何設置,才能保證 MySQL 的性能呢?在官網文檔中可以找到這個參數的一些描述:

A larger buffer pool requires less disk I/O to access the same table data more than once. On a dedicated database server, you might set the buffer pool size to 80% of the machine’s physical memory size.

意思是在專用數據庫服務器上,可以將 innodb_buffer_pool_size 設置為計算機物理內存大小的 80%。在許許多多前輩的的經驗中了解到,此參數的值設置為物理內存的 50%~80% 頗為合理。

舉個栗子:

innodb buffer pool 分配 76G,每個連接線程最大可用 160M,最大有 3000 連接數,最大可能使用內存總量 545G,但是這台實例所在服務器的物理內存僅僅有 97G,遠超物理內存總量。結果可想而知,這個實例在運行中經常被 oom-killer 殺死,想必原因之一即是因為一開始 MySQL 自身的內存規劃欠妥。

innodb buffer pool 緩存數據的作用相信大家都懂,比如這個 case 中,可以發現該實例為寫密集,讀請求很少,innodb buffer 對性能改善作用不大,80% 的內存沒必要,完全可以降低到物理內存的50%。

為什麼mysql 有的只有30多M,有的幾百M啊, 我是公司要搭建服務器,我該下載哪個?

1、30M左右的tar.gz文件是linux源碼,需要編譯安裝

34M mysql-5.6.11.tar.gz

24M mysql-5.5.31.tar.gz

msi文件是windows的安裝包

31M mysql-5.5.31-win32.msi

2、windows壓縮包

146M mysql-5.5.31-win32.zip

解壓縮,命令行進入bin目錄,執行mysqld.exe –install安裝mysql服務。

mysql服務器多大硬盤

不是,mysql的程序一共幾十兆。跟其他數據庫一樣,需要佔有多少控件要看數據庫內容的大

原創文章,作者:JEPRJ,如若轉載,請註明出處:https://www.506064.com/zh-hk/n/129707.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
JEPRJ的頭像JEPRJ
上一篇 2024-10-03 23:27
下一篇 2024-10-03 23:27

相關推薦

  • 如何修改mysql的端口號

    本文將介紹如何修改mysql的端口號,方便開發者根據實際需求配置對應端口號。 一、為什麼需要修改mysql端口號 默認情況下,mysql使用的端口號是3306。在某些情況下,我們需…

    編程 2025-04-29
  • 服務器安裝Python的完整指南

    本文將為您提供服務器安裝Python的完整指南。無論您是一位新手還是經驗豐富的開發者,您都可以通過本文輕鬆地完成Python的安裝過程。以下是本文的具體內容: 一、下載Python…

    編程 2025-04-29
  • STUN 服務器

    STUN 服務器是一個網絡服務器,可以協助網絡設備(例如 VoIP 設備)解決 NAT 穿透、防火牆等問題,使得設備可以正常地進行數據傳輸。本文將從多個方面對 STUN 服務器做詳…

    編程 2025-04-29
  • Python操作MySQL

    本文將從以下幾個方面對Python操作MySQL進行詳細闡述: 一、連接MySQL數據庫 在使用Python操作MySQL之前,我們需要先連接MySQL數據庫。在Python中,我…

    編程 2025-04-29
  • 解決docker-compose 容器時間和服務器時間不同步問題

    docker-compose是一種工具,能夠讓您使用YAML文件來定義和運行多個容器。然而,有時候容器的時間與服務器時間不同步,導致一些不必要的錯誤和麻煩。以下是解決方法的詳細介紹…

    編程 2025-04-29
  • MySQL遞歸函數的用法

    本文將從多個方面對MySQL遞歸函數的用法做詳細的闡述,包括函數的定義、使用方法、示例及注意事項。 一、遞歸函數的定義 遞歸函數是指在函數內部調用自身的函數。MySQL提供了CRE…

    編程 2025-04-29
  • MySQL bigint與long的區別

    本文將從數據類型定義、存儲空間、數據範圍、計算效率、應用場景五個方面詳細闡述MySQL bigint與long的區別。 一、數據類型定義 bigint在MySQL中是一種有符號的整…

    編程 2025-04-28
  • MySQL左連接索引不生效問題解決

    在MySQL數據庫中,經常會使用左連接查詢操作,但是左連接查詢中索引不生效的情況也比較常見。本文將從多個方面探討MySQL左連接索引不生效問題,並給出相應的解決方法。 一、索引的作…

    編程 2025-04-28
  • 如何選擇MySQL服務器文件權限

    MySQL是一種流行的關係型數據庫管理系統。在安裝MySQL時,選擇正確的文件權限是保證安全和性能的重要步驟。以下是一些指導您選擇正確權限的建議。 一、權限選擇 MySQL服務器需…

    編程 2025-04-27
  • CentOS 7在線安裝MySQL 8

    在本文中,我們將介紹如何在CentOS 7操作系統中在線安裝MySQL 8。我們會從安裝環境的準備開始,到安裝MySQL 8的過程進行詳細的闡述。 一、環境準備 在進行MySQL …

    編程 2025-04-27

發表回復

登錄後才能評論