mysql千万级数据查询-mysql教程-PHP中文網

首頁

資料庫

mysql教程

mysql千万级数据查询

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 03:46 PM

mysql大小欄位資料查詢

1. mysql 的数据查询 , 大小字段要分开 , 这个还是有必要的 , 除非一点就是你查询的都是索引内容而不是表内容 , 比如只查询 id 等等 2. 查询速度和索引有很大关系也就是索引的大小直接影响你的查询效果 , 但是查询条件一定要建立索引 , 这点上注意的是索引字

1.mysql的数据查询,大小字段要分开,这个还是有必要的,除非一点就是你查询的都是索引内容而不是表内容,比如只查询id等等
2.查询速度和索引有很大关系也就是索引的大小直接影响你的查询效果,但是查询条件一定要建立索引,这点上注意的是索引字段不能太多，太多索引文件就会很大那样搜索只能变慢,
3.查询指定的记录最好通过Id进行in查询来获得真实的数据.其实不是最好而是必须，也就是你应该先查询出复合的ID列表,通过in查询来获得数据

我们做个测试

Sql代码 mysql千万级数据查询

CREATE TABLE `ipdatas` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`uid` INT(8) NOT NULL DEFAULT '0',
`ipaddress` VARCHAR(50) NOT NULL,
`source` VARCHAR(255) DEFAULT NULL,
`track` VARCHAR(255) DEFAULT NULL,
`entrance` VARCHAR(255) DEFAULT NULL,
`createdtime` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`createddate` DATE NOT NULL DEFAULT '0000-00-00',
PRIMARY KEY (`id`),
KEY `uid` (`uid`)
) ENGINE=MYISAM AUTO_INCREMENT=67086110 DEFAULT CHARSET=utf8;

里面有七百万数据。

1.全表搜索
返回结构是67015297条数据
   SELECT COUNT(id) FROM ipdatas;
   SELECT COUNT(uid) FROM ipdatas;
   SELECT COUNT(*) FROM ipdatas;
   首先这两个全表数据查询速度很快,mysql中包含数据字典应该保留了数据库中的最大条数    SELECT COUNT(*) FROM ipdatas WHERE uid=1;   返回结果时间:2分31秒594
   SELECT COUNT(id) FROM ipdatas WHERE uid=1; 返回结果时间:1分29秒609
   SELECT COUNT(uid) FROM ipdatas WHERE uid=1; 返回结果时间:2分41秒813
   第二次查询都比较快因为mysql中是有缓存区的所以增大缓存区的大小可以解决很多查询的优化，真可谓缓存无处不在啊在程序开发中也是层层都是缓存    第一条开始查询
   SELECT * FROM ipdatas ORDER BY id DESC LIMIT 1,10 ; 31毫秒
   SELECT * FROM ipdatas LIMIT 1,10 ; 15ms    第10000条开始查询
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 10000,10 ; 266毫秒
   SELECT * FROM ipdatas LIMIT 10000,10 ; 16毫秒

   第500万条开始查询
   SELECT * FROM ipdatas LIMIT 5000000,10 ;11.312秒
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 5000000,10 ; 221.985秒
   这两条返回结果完全一样,也就是mysql默认机制就是id正序然而时间却大相径庭

   第5000万条开始查询
   SELECT * FROM ipdatas LIMIT 60000000,10 ;66.563秒 (对比下面的测试)
   SELECT * FROM ipdatas ORDER BY id ASC LIMIT 50000000,10; 1060.000秒
   SELECT * FROM ipdatas ORDER BY id DESC LIMIT 17015307,10; 434.937秒
   第三条和第二条结果一样只是排序的方式不同但是用时却相差不少，看来这点还是不如很多的商业数据库,像oracle和sqlserver等都是中间不成两边还是没问题，看来mysql是开始行越向后越慢，这里看来可以不排序的就不要排序了性能差距巨大,相差了20多倍

查询数据返回ID列表    select id from ipdatas order by id asc limit 1,10; 31ms
   SELECT id FROM ipdatas LIMIT 1,10 ; 0ms    第10000条开始
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 10000,10; 68ms
   select id from ipdatas limit 10000,10;0ms

   第500万条开始查询
   SELECT id FROM ipdatas LIMIT 5000000,10; 1.750s
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 5000000,10;14.328s

   第6000万条记录开始查询
   SELECT id FROM ipdatas LIMIT 60000000,10; 116.406s
   SELECT id FROM ipdatas ORDER BY id ASC LIMIT 60000000,10; 136.391s

   select id from ipdatas limit 10000002,10; 29.032s
   select id from ipdatas limit 20000002,10; 24.594s
   select id from ipdatas limit 30000002,10; 24.812s
   select id from ipdatas limit 40000002,10; 28.750s 84.719s
   select id from ipdatas limit 50000002,10; 30.797s 108.042s
   select id from ipdatas limit 60000002,10; 133.012s 122.328s

   select * from ipdatas limit 10000002,10; 27.328s
   select * from ipdatas limit 20000002,10; 15.188s
   select * from ipdatas limit 30000002,10; 45.218s
   select * from ipdatas limit 40000002,10; 49.250s   50.531s
   select * from ipdatas limit 50000002,10; 73.297s   56.781s
   select * from ipdatas limit 60000002,10; 67.891s   75.141s

   select id from ipdatas order by id asc limit 10000002,10; 29.438s
   select id from ipdatas order by id asc limit 20000002,10; 24.719s
   select id from ipdatas order by id asc limit 30000002,10; 25.969s
   select id from ipdatas order by id asc limit 40000002,10; 29.860d
   select id from ipdatas order by id asc limit 50000002,10; 32.844s
   select id from ipdatas order by id asc limit 60000002,10; 34.047s

   至于SELECT * ipdatas order by id asc 就不测试了大概都在十几分钟左右
   可见通过SELECT id 不带排序的情况下差距不太大,加了排序差距巨大    SELECT * FROM ipdatas WHERE id IN (10000,100000,500000,1000000,5000000,10000000,2000000,30000000,40000000,50000000,60000000,67015297);
   耗时0.094ms
   可见in在id上面的查询可以忽略不计毕竟是6000多万条记录，所以为什么很多lucene或solr搜索都返回id进行数据库重新获得数据就是因为这个,当然lucene/solr+mysql是一个不错的解决办法这个非常适合前端搜索技术,比如前端的分页搜索通过这个可以得到非常好的性能.还可以支持很好的分组搜索结果集,然后通过id获得数据记录的真实数据来显示效果真的不错

陳述

本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

MySQL中的存儲過程是什麼？May 01, 2025 am 12:27 AM

存儲過程是MySQL中的預編譯SQL語句集合，用於提高性能和簡化複雜操作。 1.提高性能：首次編譯後，後續調用無需重新編譯。 2.提高安全性：通過權限控制限制數據表訪問。 3.簡化複雜操作：將多條SQL語句組合，簡化應用層邏輯。

查詢緩存如何在MySQL中工作？May 01, 2025 am 12:26 AM

MySQL查詢緩存的工作原理是通過存儲SELECT查詢的結果，當相同查詢再次執行時，直接返回緩存結果。 1）查詢緩存提高數據庫讀取性能，通過哈希值查找緩存結果。 2）配置簡單，在MySQL配置文件中設置query_cache_type和query_cache_size。 3）使用SQL_NO_CACHE關鍵字可以禁用特定查詢的緩存。 4）在高頻更新環境中，查詢緩存可能導致性能瓶頸，需通過監控和調整參數優化使用。

與其他關係數據庫相比，使用MySQL的優點是什麼？May 01, 2025 am 12:18 AM

MySQL被廣泛應用於各種項目中的原因包括：1.高性能與可擴展性，支持多種存儲引擎；2.易於使用和維護，配置簡單且工具豐富；3.豐富的生態系統，吸引大量社區和第三方工具支持；4.跨平台支持，適用於多種操作系統。

您如何處理MySQL中的數據庫升級？Apr 30, 2025 am 12:28 AM

MySQL數據庫升級的步驟包括：1.備份數據庫，2.停止當前MySQL服務，3.安裝新版本MySQL，4.啟動新版本MySQL服務，5.恢復數據庫。升級過程需注意兼容性問題，並可使用高級工具如PerconaToolkit進行測試和優化。

您可以使用MySQL的不同備份策略是什麼？Apr 30, 2025 am 12:28 AM

MySQL備份策略包括邏輯備份、物理備份、增量備份、基於復制的備份和雲備份。 1.邏輯備份使用mysqldump導出數據庫結構和數據，適合小型數據庫和版本遷移。 2.物理備份通過複製數據文件，速度快且全面，但需數據庫一致性。 3.增量備份利用二進制日誌記錄變化，適用於大型數據庫。 4.基於復制的備份通過從服務器備份，減少對生產系統的影響。 5.雲備份如AmazonRDS提供自動化解決方案，但成本和控制需考慮。選擇策略時應考慮數據庫大小、停機容忍度、恢復時間和恢復點目標。

什麼是mySQL聚類？Apr 30, 2025 am 12:28 AM

MySQLclusteringenhancesdatabaserobustnessandscalabilitybydistributingdataacrossmultiplenodes.ItusestheNDBenginefordatareplicationandfaulttolerance,ensuringhighavailability.Setupinvolvesconfiguringmanagement,data,andSQLnodes,withcarefulmonitoringandpe

如何優化數據庫架構設計以在MySQL中的性能？Apr 30, 2025 am 12:27 AM

在MySQL中優化數據庫模式設計可通過以下步驟提升性能：1.索引優化：在常用查詢列上創建索引，平衡查詢和插入更新的開銷。 2.表結構優化：通過規範化或反規範化減少數據冗餘，提高訪問效率。 3.數據類型選擇：使用合適的數據類型，如INT替代VARCHAR，減少存儲空間。 4.分區和分錶：對於大數據量，使用分區和分錶分散數據，提升查詢和維護效率。

您如何優化MySQL性能？Apr 30, 2025 am 12:26 AM

tooptimizemysqlperformance，lofterTheSeSteps：1）inasemproperIndexingTospeedUpqueries，2）使用ExplaintplaintoAnalyzeandoptimizequeryPerformance，3）ActiveServerConfigurationStersLikeTlikeTlikeTlikeIkeLikeIkeIkeLikeIkeLikeIkeLikeIkeLikeNodb_buffer_pool_sizizeandmax_connections，4）

See all articles