解決mysql的內存表“table is full”錯誤


最后參考http://blog.sina.com.cn/s/blog_6942a1590101429h.html 來解決,摘錄下核心

后來GOOGLE得知,需要重建該表才可以。

1. 設置新的參數

mysql> set global max_heap_table_size=1048576000

mysql> set global tmp_table_size=1048576000

2. 修改mysql配置文件,使得mysql重新啟動時變動能夠持續生效。

3. 最后,你需要重新連上MYSQL,重新創建相關的內存表。

mysql> ALTER TABLE zaojiao_sessions ENGINE MEMORY;

4. 最后,當應用重新連接到mysql數據庫時,這些變更就生效了。

我自家加的:

centos下,my.cnf在/etc下,大概需要修改下那個文件,可以在mysqld重啟后也能使用了。

ip地址庫,根據ip查到具體的國家省市,經緯度,

采用內存表的方式,大概需要0.95秒;如果提前載入到有序列表,用內存換取時間,采用折半查找法,

列表的長度是:3767093,查到一個具體的值'207.46.250.101'的時間,分別試了兩次:68納秒,72納米。在忙碌的windows機上是1000納秒左右。很簡單的程序,windows下消耗的內存是1.5G。

 

下面說說用內存表的情況:

先做設置:

set global max_heap_table_size=1048576000;
set global tmp_table_size=1048576000;

drop table ipv4_zh_mem;
CREATE TABLE `ipv4_zh_mem` (
`Start_Num` bigint(20) DEFAULT NULL,
`End_Num` bigint(20) DEFAULT NULL,
`country_name` varchar(256) COLLATE utf8_unicode_ci,
`subdivision_1_name` varchar(64) COLLATE utf8_unicode_ci,
`city_name` varchar(256) COLLATE utf8_unicode_ci,
`latitude` varchar(64),
`longitude` varchar(64)
) engine = memory;
create index memIndex on ipv4_zh_mem(Start_Num, End_Num);
insert into ipv4_zh_mem select Start_Num, End_Num, country_name, subdivision_1_name, city_name, latitude, longitude from ipv4_zh_full;

select * from ipv4_zh_mem limit 10;
select country_name, subdivision_1_name, city_name, latitude, longitude from ipv4_zh_mem where 3475962469 between Start_Num and End_Num;

最后一行執行的時間,為1.7s左右。之前沒有用COLLATE utf8_unicode_ci的時候,執行的時間是0.95s。

說明: ipv4_zh_full的體積大概是600多M。系統缺省配置的內存表的限制是512M,所以必須更改限制。

編碼方面的內容參考:http://blog.sina.com.cn/s/blog_6dbcbffc0100wvk3.html,為了處理中文的情況,需要修改my.cnf或者my.ini(windows下)

[mysqld]
default-character-set=utf8
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
[mysql]
default-character-set=utf8


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM