本篇文章帶給大家的內容是關於針對javaweb中的表格查詢進行的sql的優化介紹，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。
背景
本次SQL最佳化是針對javaweb中的表格查詢所做的。
N個機器將業務資料傳送至伺服器，伺服器程式將資料入庫至MySQL資料庫。伺服器中的javaweb程式將資料展示到網頁上供使用者查看。
windows單機主從分離
#已分錶分庫，按年分庫，按天分錶
每張表大概20w左右的資料
3天資料查詢70- 80s
3-5s
無法使用sql分頁，只能用java做分頁。
#如果你配置了druid，可在druid頁面中直接查看sql執行時間和uri請求時間
在後台程式碼中用System.currentTimeMillis計算時間差。
結論： 後台慢，且查詢sql慢
sql拼接過長，達到了3000行，有的甚至到8000行，大多都是union all的操作，且有不必要的嵌套查詢和查詢了不必要的字段
利用explain查看執行計劃，where條件中除時間外只有一個字段用到了索引
備註： 因優化完了，之前的sql實在找不到了，這裡只能YY了。
效果沒那麼明顯
效果沒那麼明顯
將union all的運算分解，例如(一個union all的sql也很長)
select aa from bb_2018_10_01 left join ... on .. left join .. on .. where .. union all select aa from bb_2018_10_02 left join ... on .. left join .. on .. where .. union all select aa from bb_2018_10_03 left join ... on .. left join .. on .. where .. union all select aa from bb_2018_10_04 left join ... on .. left join .. on .. where ..
將如上sql分解成若干個sql去執行，最終匯總數據，最後快了20s左右。
select aa from bb_2018_10_01 left join ... on .. left join .. on .. where ..
select aa from bb_2018_10_02 left join ... on .. left join .. on .. where ..
利用java非同步程式設計的操作，將分解的sql異步執行並最終匯總資料。這裡用到了CountDownLatch和ExecutorService，範例程式碼如下：
// 获取时间段所有天数
List<String> days = MyDateUtils.getDays(requestParams.getStartTime(), requestParams.getEndTime());
// 天数长度
int length = days.size();
// 初始化合并集合，并指定大小，防止数组越界
List<你想要的数据类型> list = Lists.newArrayListWithCapacity(length);
// 初始化线程池
ExecutorService pool = Executors.newFixedThreadPool(length);
// 初始化计数器
CountDownLatch latch = new CountDownLatch(length);
// 查询每天的时间并合并
for (String day : days) {
Map<String, Object> param = Maps.newHashMap();
// param 组装查询条件
pool.submit(new Runnable() {
@Override
public void run() {
try {
// mybatis查询sql
// 将结果汇总
list.addAll(查询结果);
} catch (Exception e) {
logger.error("getTime异常", e);
} finally {
latch.countDown();
}
}
});
}
try {
// 等待所有查询结束
latch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
// list为汇总集合
// 如果有必要，可以组装下你想要的业务数据，计算什么的，如果没有就没了結果又快了20-30s
#以下是我的設定範例。加了skip-name-resolve,快了4-5s。其他配置自行斷定
[client] port=3306 [mysql] no-beep default-character-set=utf8 [mysqld] server-id=2 relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin slave-skip-errors=all #跳过所有错误 skip-name-resolve port=3306 datadir="D:/mysql-slave/data" character-set-server=utf8 default-storage-engine=INNODB sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" log-output=FILE general-log=0 general_log_file="WINDOWS-8E8V2OD.log" slow-query-log=1 slow_query_log_file="WINDOWS-8E8V2OD-slow.log" long_query_time=10 # Binary Logging. # log-bin # Error Logging. log-error="WINDOWS-8E8V2OD.err" # 整个数据库最大连接（用户）数 max_connections=1000 # 每个客户端连接最大的错误允许数量 max_connect_errors=100 # 表描述符缓存大小，可减少文件打开/关闭次数 table_open_cache=2000 # 服务所能处理的请求包的最大大小以及服务所能处理的最大的请求大小(当与大的BLOB字段一起工作时相当必要) # 每个连接独立的大小.大小动态增加 max_allowed_packet=64M # 在排序发生时由每个线程分配 sort_buffer_size=8M # 当全联合发生时,在每个线程中分配 join_buffer_size=8M # cache中保留多少线程用于重用 thread_cache_size=128 # 此允许应用程序给予线程系统一个提示在同一时间给予渴望被运行的线程的数量. thread_concurrency=64 # 查询缓存 query_cache_size=128M # 只有小于此设定值的结果才会被缓冲 # 此设置用来保护查询缓冲,防止一个极大的结果集将其他所有的查询结果都覆盖 query_cache_limit=2M # InnoDB使用一个缓冲池来保存索引和原始数据 # 这里你设置越大,你在存取表里面数据时所需要的磁盘I/O越少. # 在一个独立使用的数据库服务器上,你可以设置这个变量到服务器物理内存大小的80% # 不要设置过大,否则,由于物理内存的竞争可能导致操作系统的换页颠簸. innodb_buffer_pool_size=1G # 用来同步IO操作的IO线程的数量 # 此值在Unix下被硬编码为4,但是在Windows磁盘I/O可能在一个大数值下表现的更好. innodb_read_io_threads=16 innodb_write_io_threads=16 # 在InnoDb核心内的允许线程数量. # 最优值依赖于应用程序,硬件以及操作系统的调度方式. # 过高的值可能导致线程的互斥颠簸. innodb_thread_concurrency=9 # 0代表日志只大约每秒写入日志文件并且日志文件刷新到磁盘. # 1 ,InnoDB会在每次提交后刷新(fsync)事务日志到磁盘上 # 2代表日志写入日志文件在每次提交后,但是日志文件只有大约每秒才会刷新到磁盘上 innodb_flush_log_at_trx_commit=2 # 用来缓冲日志数据的缓冲区的大小. innodb_log_buffer_size=16M # 在日志组中每个日志文件的大小. innodb_log_file_size=48M # 在日志组中的文件总数. innodb_log_files_in_group=3 # 在被回滚前,一个InnoDB的事务应该等待一个锁被批准多久. # InnoDB在其拥有的锁表中自动检测事务死锁并且回滚事务. # 如果你使用 LOCK TABLES 指令, 或者在同样事务中使用除了InnoDB以外的其他事务安全的存储引擎 # 那么一个死锁可能发生而InnoDB无法注意到. # 这种情况下这个timeout值对于解决这种问题就非常有帮助. innodb_lock_wait_timeout=30 # 开启定时 event_scheduler=ON
快4-5s
效果沒那麼明顯
針對這條，我自身覺得很詬異。原sql,b為索引
select aa from bb_2018_10_02 left join ... on .. left join .. on .. where b = 'xxx'
應該之前有union all，union all是一個的執行，最後一個匯總的結果。修改為
select aa from bb_2018_10_02 left join ... on .. left join .. on .. inner join
(
select 'xxx1' as b2
union all
select 'xxx2' as b2
union all
select 'xxx3' as b2
union all
select 'xxx3' as b2
) t on b = t.b2結果快了3-4s
根據上述操作，3天查詢效率已經達到了8s左右，再也快不了了。查看mysql的cpu使用率和記憶體使用率都不高，到底為什麼查這麼慢了，3天最多才60w數據，關聯的也都是一些字典表，不至於如此。繼續根據網路上提供的資料，一系列騷操作，基本上沒用，沒轍。
因為分析過sql優化已經ok了，試想是不是磁碟讀寫問題。將優化過的程序，分別部署於不同的現場環境。一個有ssd，一個沒有ssd。發現查詢效率懸殊。用軟體偵測過發現ssd讀寫速度在700-800M/s,普通機械硬碟讀寫在70-80M/s。
優化結果：達到預期。
最佳化結論：sql最佳化不只是對sql本身的最佳化，還取決於本身硬體條件，其他應用的影響，外加自身程式碼的最佳化。
以上就是這篇文章的全部內容了，關於Java的更多精彩可以關注PHP中文網的Java視頻教程和Java開發教程欄位！ ！ ！
以上是針對javaweb中的表格查詢進行的sql的最佳化介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！
