如何擴(kuò)大linux下mysql的存儲空間？

再/etc/my.cnf把指定到有空間的目錄中

專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)嘉魚免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了千余家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

比如

[mysqld]

datadir=/var/mysql/data存放數(shù)據(jù)庫

數(shù)據(jù)庫空間滿了怎么處理

1：分離數(shù)據(jù)庫 企業(yè)管理器－＞服務(wù)器－＞數(shù)據(jù)庫－＞右鍵－＞分離數(shù)據(jù)庫

2：刪除LOG文件

3：附加數(shù)據(jù)庫 企業(yè)管理器－＞服務(wù)器－＞數(shù)據(jù)庫－＞右鍵－＞附加數(shù)據(jù)庫

此法生成新的LOG，大小只有500多K

再將此數(shù)據(jù)庫設(shè)置自動收縮

或用代碼分離 pubs，然后將 pubs 中的一個文件附加到當(dāng)前服務(wù)器：

EXEC sp_detach_db @dbname = 'pubs'

EXEC sp_attach_single_file_db @dbname = 'pubs',

@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'

如何加mysql5.5運行內(nèi)存

每個連接到MySQL服務(wù)器的線程都需要有自己的緩沖。大概需要立刻分配256K，甚至在線程空閑時 — 它們使用默認(rèn)的線程堆棧，網(wǎng)絡(luò)緩存等。事務(wù)開始之后，則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內(nèi)存消耗，然而如果對數(shù)據(jù)表做復(fù)雜的操作例如掃描、排序或者需要臨時表，則需分配大約 read_buffer_size, sort_buffer_size, read_rnd_buffer_size, tmp_table_size 大小的內(nèi)存空間。不過它們只是在需要的時候才分配，并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊，例如 tmp_table_size 可能高達(dá)MySQL所能分配給這個操作的最大內(nèi)存空間了。注意，這里需要考慮的不只有一點 — 可能會分配多個同一種類型的緩存，例如用來處理子查詢。一些特殊的查詢的內(nèi)存使用量可能更大 — 如果在MyISAM表上做成批的插入時需要分配 bulk_insert_buffer_size 大小的內(nèi)存。執(zhí)行 ALTER TABLE, OPTIMIZE TABLE, REPAIR TABLE 命令時需要分配 myisam_sort_buffer_size 大小的內(nèi)存。

For OLTP applications with simple queries memory consumption is often less than 1MB per thread with default buffers, and you really do not need to increase per thread buffers unless you have complex queries. Sorting 10 rows will be as fast with 1MB sort buffer as with 16MB （actually 16MB might be even slower but it is other story）。

只有簡單查詢OLTP應(yīng)用的內(nèi)存消耗經(jīng)常是使用默認(rèn)緩沖的每個線程小于1MB，除非需要使用復(fù)雜的查詢否則無需增加每個線程的緩沖大小。使用1MB的緩沖來對10行記錄進(jìn)行排序和用16MB的緩沖基本是一樣快的（實際上16MB可能會更慢，不過這是其他方面的事了）。

Another approach you may take is to come up with amount of memory you want MySQL Server to consume at peak. This can be easily computed by memory needed for OS, File Cache and other applications. For 32bit envinronment you also should keep 32bit limits into account and probably limit “mysqld” size to about 2.5GB （exact number depens on a lot of factors）。 Now you can use “ps aux” to see VSZ - Virtual Memory allocated by MySQL process. You can also look at “Resident Memory” but I find it less helpful as it may down because of swapping - not what you would like to see. Monitor how the value changes so you know memory requirements with current settings and increase/decrease values appropriately.

另外，就是找出MySQL服務(wù)器內(nèi)存消耗的峰值。這很容易就能計算出操作系統(tǒng)所需的內(nèi)存、文件緩存以及其他應(yīng)用。在32位環(huán)境下，還需要考慮到32位的限制，限制 “mysqld” 的值大約為2.5G（實際上還要考慮到很多其他因素）?，F(xiàn)在運行 “ps aux” 命令來查看 VSZ 的值 — MySQL 進(jìn)程分配的虛擬內(nèi)存。也可以查看 “Resident Memory” 的值，不過我想它可能沒多大用處，因為它會由于交換而變小 — 這并不是你想看到的。監(jiān)視著內(nèi)存變化的值，就能知道是需要增加/減少當(dāng)前的內(nèi)存值了。

Some may say, Hey we want to have 100% guarantee our server will never run out of memory, no matter which queries or users will decide to run. Unfortunately this is as much close to impossible to be impractical. Here is why:

List of rarely considered MySQL Server Memory Requirements

以下是很少考慮的MySQL服務(wù)器內(nèi)存需求

Thread buffers can be allocated more than once for each thread. Consider for example subqueries - each layer may need its own read_buffer,sort_buffer, tmp_table_size etc每個線程可能會不止一次需要分配緩沖。 考慮到例如子查詢 — 每層都需要有自己的 read_buffer,sort_buffer, tmp_table_size 等。Many variabes can be set per connection. So you can't relay on global values if developers may use their local values to run some queries.在每個連接中很多變量都可能需要重新設(shè)置。 如果開發(fā)者想設(shè)定自己的變量值來運行某些查詢就不能繼續(xù)使用全局值。There can be mutiple key caches. Multiple key caches can be created to accomodate query executions可能有多個索引緩存。 為了配合執(zhí)行查詢可能會創(chuàng)建多個索引緩存。Query Parsing and optimization needs memory. This is usually small to be ignored but certain queries can have very large memory requrement for this step, especially specially crafted ones.解析查詢和優(yōu)化都需要內(nèi)存。 這些內(nèi)存通常比較小，可以忽略，不過如果是某些查詢在這個步驟中則需要大量內(nèi)存，尤其是那些設(shè)計的比較特別的查詢。Stored Procedures. Compex stored procedures may require a lot of memory存儲過程。 復(fù)雜的存儲過程可能會需要大量內(nèi)存。Prepared statements and Cursors. Single connection may have many prepared statements and cursors. Their number finally can be limited but each of them still can have very large memory consumption準(zhǔn)備查詢語句以及游標(biāo)。 單次鏈接可能會有很多的準(zhǔn)備好的語句以及游標(biāo)。它們的數(shù)量最后可以限定，但是仍然會消耗大量的內(nèi)存。Innodb Table Cache. Innodb has its own table cache in which meta data about each table accessed from the start is stored. It is never purged and may be large if you have a lot of tables. It also means user having CREATE TABLE privilege should be able to run MySQL server out of memoryInnodb表緩存。 Innnodb表有自己的緩存，它保存了從一開始訪問每個表的元數(shù)據(jù)。它們從未被清除過，如果有很多Innodb表的話，那么這個量就很大了。這也就意味著擁有 CREATE TABLE 權(quán)限的用戶就可能把MySQL服務(wù)器的內(nèi)存耗盡。MyISAM buffers. MyISAM may allocate buffer which is large enough to contain largest record in the given table which is held until table is closed.MyISAM緩沖。 MyISAM表可能會分配一個足以裝下指定表最大記錄的緩沖，而且這個緩沖直到表關(guān)閉了才釋放。Federated Storage Engine. This may have unbound memory requirements retriving result sets from remove queries.FEDERATED存儲引擎。 This may have unbound memory requirements retriving result sets from remove queries.Blobs may require 3x time of memory. This is important if you're deaing with large Blobs （your max_allowed_packet is large） Processing of 256MB of blob may require 768MB of memory.Blobs可能需要3倍的內(nèi)存。 這在處理很大（max_allowed_packet 的值較大）的Blobs數(shù)據(jù)時很重要，如果處理256MB的數(shù)據(jù)可能需要768MB的內(nèi)存。Storage Engines. In general storage engines may have their own per thread or global memory allocations which are not tuned as buffers. Watch for these especially now with many storage engines being released for MySQL by various parties.存儲引擎。 通常情況下，存儲引擎會設(shè)置自己的每個線程的全局分配內(nèi)存，它通常不能像緩存一樣可以調(diào)節(jié)?，F(xiàn)在應(yīng)該通過各種方式來特別關(guān)注MySQL釋放出來的存儲引擎。 I do not pretend this to be complete list. On the contrary I'm quite sure I've missed something （drop me a note if you have something to add）。 But the main point is - there are a lot of memory consumers out where and trying to find peak possible usage for each is impractical - so my advice would be measure what you get in practice and how memory consumption reacts to changing various variables. For example you may find out increasing sort_buffer_size from 1MB to 4MB and 1000 max_connections increases peak memory consumption just 30MB not 3000MB as you might have counted.

我想這還不是完成的列表，相反地，我覺得還是漏掉了一些（如果你知道，請給我回復(fù)加上）。但主要的原因是 — 找到每次內(nèi)存消耗峰值是不切實際的，因此我的這些建議可以用來衡量一下你實際修改一些變量值產(chǎn)生的反應(yīng)。例如，把 sort_buffer_size 從1MB增加到4MB并且在 max_connections 為 1000 的情況下，內(nèi)存消耗增長峰值并不是你所計算的3000MB而是30MB。

Mysql中的內(nèi)存分配相關(guān)配置參數(shù)這些參數(shù)可以分成兩部分，分別對應(yīng)MySQL中的兩個層次：服務(wù)器層和存儲引擎層。MySQL服務(wù)器相關(guān)：

每個連接到MySQL服務(wù)器的線程都需要有自己的緩沖，默認(rèn)為其分配256K。事務(wù)開始之后，則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內(nèi)存消耗，例如存儲查詢語句的空間等。但如果對數(shù)據(jù)表做復(fù)雜的操作比較復(fù)雜，例如排序則需要使用臨時表，此時會分配大約 read_buffer_size，sort_buffer_size，read_rnd_buffer_size，tmp_table_size大小的內(nèi)存空間。不過它們只是在需要的時候才分配，并且在那些操作做完之后就釋放了。read_buffer_size是MySql讀入緩沖區(qū)大小。對表進(jìn)行順序掃描的請求將分配一個讀入緩沖區(qū)，MySql會為它分配一段內(nèi)存緩沖區(qū)。read_buffer_size變量控制這一緩沖區(qū)的大小。如果對表的順序掃描請求非常頻繁，并且你認(rèn)為頻繁掃描進(jìn)行得太慢，可以通過增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能。sort_buffer_size是MySql執(zhí)行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小。該變量會監(jiān)測sort_merge_passed, sort_range, sort_rows, sort_scan的狀況。通常較小的sort_merge_passed性能越高，但是也與workload的特性有關(guān)。read_rnd_buffer_size是MySql的隨機(jī)讀緩沖區(qū)大小。當(dāng)按任意順序讀取行時（例如，按照排序順序），將分配一個隨機(jī)讀緩存區(qū)。進(jìn)行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數(shù)據(jù)，可適當(dāng)調(diào)高該值。但MySql會為每個客戶連接發(fā)放該緩沖空間，所以應(yīng)盡量適當(dāng)設(shè)置該值，以避免內(nèi)存開銷過大。

query_cache_size是MySql的查詢緩沖大小。（從4.0.1開始，MySQL提供了查詢緩沖機(jī)制）使用查詢緩沖，MySQL將 SELECT語句和查詢結(jié)果存放在緩沖區(qū)中，今后對于同樣的SELECT語句（區(qū)分大小寫），將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊，使用查詢緩沖最多可以達(dá)到238%的效率。此外還有每個連接中會使用的一些變量會消耗少量內(nèi)存。MyISAM引擎相關(guān)

key_buffer_size存儲了所有index的緩存，一般我們設(shè)為16M，通過檢查狀態(tài)值Key_read_requests和 Key_reads，可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好（上述狀態(tài)值可以使用‘key_read%’獲得用來顯示狀態(tài)數(shù)據(jù)）。key_buffer_size只對MyISAM表起作用。即使不使用MyISAM存儲引擎，但是內(nèi)部的臨時磁盤表是MyISAM表，故也要使用該值。InnoDB引擎相關(guān)

innodb_buffer_pool_size對于InnoDB表來說，作用就相當(dāng)于key_buffer_size對于MyISAM表的作用一樣。InnoDB使用該參數(shù)指定大小的內(nèi)存來緩沖數(shù)據(jù)和索引。對于單獨的MySQL數(shù)據(jù)庫服務(wù)器，手冊上推薦把該值設(shè)置成物理內(nèi)存的80%。

innodb_additional_mem_pool_size指定InnoDB用來存儲數(shù)據(jù)字典和其他內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存池大小。缺省值是1M。通常不用太大，只要夠用就行，應(yīng)該與表結(jié)構(gòu)的復(fù)雜度有關(guān)系。如果不夠用，MySQL會在錯誤日志中寫入一條警告信息。

innodb_log_buffer_size指定InnoDB用來存儲日志數(shù)據(jù)的緩存大小，如果您的表操作中包含大量并發(fā)事務(wù)（或大規(guī)模事務(wù)），并且在事務(wù)提交前要求記錄日志文件，請盡量調(diào)高此項值，以提高日志效率。

Linux下的mysql數(shù)據(jù)庫爆滿了 ，現(xiàn)在沒法連接數(shù)據(jù)庫 求高手解答。在線等

數(shù)據(jù)庫文件可以拷貝出來的。另外，磁盤空間的問題，你可以刪些無關(guān)的內(nèi)容啊……

比如 /usr/share 里面的 man 和 doc 什么的，先拷貝到 U 盤上，之后刪了騰出空間，把數(shù)據(jù)庫數(shù)據(jù)導(dǎo)出來后再恢復(fù)這些臨時刪掉的數(shù)據(jù)就行了。

一般來說，你可以先試試刪掉舊的不用的 log 。

mysql數(shù)據(jù)庫滿了

已經(jīng)滿了是沒辦法優(yōu)化的，只有增加空間，或者刪除部分不用的數(shù)據(jù)庫