普通视图

发现新文章,点击刷新页面。
昨天以前首页

使用内部数据就会卡?

作者 xrspook
2025年4月12日 08:35

当年今日

昨天说到一个很简单的SQL语句引用的数据库就只有一个字段两行记录,居然需要24秒才能得出结果。这让我觉得非常不可思议。首先可以肯定的是数据量非常少,为什么会出现这种问题呢?那只能是连接方面是不是出了什么故障,也不能说,那是失效的,因为的确还能查询得到想要查询的东西。在我测试的那个宏里面。我引用了两个文件,一个是外部文件,一个是内部文件。外部文件是含有比较多的数据,而内部文件,也就是我一开始说的那个只有两条数据。我感觉如果我的SQL再厉害一些,我对VBA再熟悉一些的话,那个内部文件可能我就不需要引用了,我直接就在VBA里创建一个数据库,然后把两条数据给写进去,用完以后就删掉,但显然现在我还没有很大的把握,一定能完美地做这件事情。把我某个文件里面的数据转化为数据库的数据我又烂熟,所以我采取了现在使用的这种方式。

ADO+SQL的这种方式,因为我们是跨表引用,所以意味着数据肯定来源于多个文件。他们有可能是同一个工作簿的不同工作表,也有可能是在不同的工作簿里。对我来说,只要是在一个工作簿里,那么起码一开始设定指向的时候就得有一个数据源。最经典的方式引用的那个数据源在使用数据的时候,在from后面不需要进行进一步的引用,其它的就得麻烦一些。我的第一个反应是,是不是引用数据的那个语句出现了变动呢?比如说现在我用的是Excel12。在数据源引用方面,我又折腾了一番,发现好像还是那样,没什么进展。会拖慢查询的那个数据源,我甚至把它放到了主数据源里,结果发现还是很慢,于是这就排除了是数据源引用语句变动导致缓慢。

所以这到底是什么原因造成的呢?因为我有很多个跨表引用的查询。有些查询是内部数据外部数据都有,有些只有外部数据,经过测试后我发现好像只有引用了内部数据的查询才会变慢。

为了证明我这个想法,星期三的晚上我编造了一些数据做测试。主要原理就是研究是不是数据源的关系导致这种变慢。一开始我的设计就是一个排列组合的方式,因为我默认的数据引用是要跨表的,所以我把数据源根据内内、内外、外外和外内这4种方式测试,实际上内内和外外是一回事,也就不需要进行两个引用了,所以我又把那两个东西拿了出来,同样进行测试。结果让人有点吃惊,凡是有内部数据参与的查询都会变慢。我测试的数据就只有一个字段几条记录,内内和内外需要12秒,外外需要0.1秒,外内需要24秒。这就能解释为什么我的那些变慢的查询起码都要24秒才能出结果。因为我永远把内部数据放在后面。究其原因是因为我设计那些查询的时候,我后来才想到要在那个查询文件里面搭一个加脚手架,把一些基础的东西加上去,在这种情况下我加得最多的是日期表。

关于这个测试的来龙去脉以及最终的结果,我在ExcelHome里面做了一个详细的帖子,在这里就不再具体阐述了。

折腾了这么一番以后,我发现这个锅还真不是我整出来的。造锅的是微软,不知道更新出了什么状况导致了。

Excel用多了,不知不觉我也居然能挑出微软的毛病。

查询突然变慢

作者 xrspook
2025年4月11日 08:14

当年今日

周三的下午跟往常一样,我点一下自己写的ADO+SQL+VBA的跨表查询文件,结果发现之前一秒就能出结果的东西等了好久,鼠标在那里转圈,我都甚至怀疑是Excel不知道因为什么原因卡死了,但我又有理由相信这不是卡死,因为当VBA要运行很长时间的时候,就会出现那种假死的状态。以前我遇到过这种情况,当我要查询一整年的平均库存的时候,就会这样,如果只是查询一个月的,没有问题。之所以一整年会出状况,是因为需要处理的数据的确有点多,如果我用的不是Excel的VBA的SQL,如果我要做的那个平均库存是在数据库里,用正儿八经规范标准的SQL做,我感觉不需要那么长时间。要长时间运行,无可避免会出现假死状态。周三下午,我就经历了一次,但我觉得那个查询不应该会假死。那个查询文件我用了接近两年,一直以来都没什么问题,因为数据不多,很简单,所以正常情况下,一秒之内出结果。其它查询可能需要的时间长一点,因为涉及的数据量比较大,但是这一次让我卡死的那个,一直以来,当我测试成功通过以后,就没有卡死过。

为什么会这样呢?我把自己写的所有查询文件全部都点了一遍。我觉得既然最简单的那个都要卡24秒,那些之前需要更长运行时间,会让人疯掉。测试结果让我有点意外。我猜想会更疯狂的那些居然没事,跟以前一样,运行时间没什么区别,但有些我感觉没有难度的东西,反倒卡住了。最卡的那个卡了97秒,实际上那个查询平时只需要0.5秒。

遇到这种情况,首先我不觉得是因为我的查询文件出了状况,因为这几天它没改动过,除非有人动了我的电脑,但这个几率太低。我觉得出状况最大的可能性是那个源文件的结构发生了某些变化,因为我引用的是Excel文件。用的那个范围是一个超级表,而如果在那个超级表以外的某个地方出现了一些奇怪的数据,比如说在纯日期的列里面出现了文本,那么就会导致在SQL转化数据的过程之中出现一些意想不到的事情。为了避免这种事情,我把源数据的那些空白行和列全部都删除处理。这就保证了我的原始数据是符合规定的,和以前的格式是一致的。接下来我觉得这会不会是更新的问题,所以我对windows系统以及Microsoft 365都进行了手动的更新。这两个东西的确都是需要安装更新的。更新完成了以后,问题依旧。

接下来我有两个选择,一个是就这样等死,反正现在的情况也不是出不了查询结果,只是用时很长而已。万一这真的是微软升级的bug,说不定哪一天他们就会解决掉,但也说不准他们永远都不解决这个我认为是bug的问题。第二个选择是我主动出击,逐个测试VBA查询里的语句。找出那条让我运行时间很长的语句,然后判定到底是什么原因。

那个理论上一秒就应该结束的查询,实际上是Excel工作表里面汇集了多个汇总查询。我只是把结果都在一个页面展示而已,所以首先,我要找出导致最终结果很慢的是哪个查询。这是一个反推的过程。让我有点意外的是,那些涉及很多数据的查询居然都没有问题,一个我觉得根本不会出问题的问东西里居然出问题了。出问题的那个查询实际上只涉及了一个字段两条数据。这简直让我震惊了,怎么居然这样呢?

这个问题是我之前没有遇到过的,但从发现这个奇葩之后,我觉得自己有点跟那杠上了。

MySQL参数一键配置脚本: 有效提升数据库性能


我一直是自己租用VPS服务器,然后搭建各种服务,比如博客就是Apache2+MySQL数据库。一般来说就是默认参数,没有去管,不过最近发现MySQL的性能参数都很保守,不能发挥整个服务器的性能。

然后我就网上搜索了一下,根据参数配置建议,用ChatGPT写了以下Python和BASH脚本。只需要在需要优化的服务器上,跑一下该脚本,然后就会显示参数配置,然后直接把参数添加到MySQL数据库配置参数文件上: /etc/mysql/mysql.conf.d/mysqld.cnf

然后运行: service mysql restart 重启MySQL服务器。

运行了几周,发现效果很好,博客反应速度也快了很多,这很大原因是根据了内存增加了MySQL缓存大小。

Python脚本优化MySQL数据库参数

把下面的Python脚本存成 mysql_config.py 然后运行 python3 mysql_config.py

def get_total_ram():
    with open('/proc/meminfo', 'r') as f:
        for line in f:
            if line.startswith("MemTotal:"):
                total_ram_kb = int(line.split()[1])
                return total_ram_kb * 1024  # 转换为字节(bytes)
    return 0  # 如果未找到 MemTotal,则返回 0

def calculate_mysql_settings():
    # 获取总内存(以字节为单位)
    total_ram = get_total_ram()

    # 根据总内存(以字节为单位)计算 MySQL 配置
    innodb_buffer_pool_size = int(total_ram * 0.3)  # 使用内存的 30%
    key_buffer_size = min(total_ram * 20 // 100, 512 * 1024 * 1024)  # 使用内存的 20%,最大限制为 512MB
    sort_buffer_size = min(total_ram * 25 // 1000, 4 * 1024 * 1024)  # 使用内存的 0.25%,最大限制为 4MB
    read_rnd_buffer_size = min(total_ram * 625 // 100000, 512 * 1024)  # 使用内存的 0.0625%,最大限制为 512KB
    tmp_table_size = max_heap_table_size = min(total_ram * 5 // 100, 64 * 1024 * 1024)  # 使用内存的 5%,最大限制为 64MB
    join_buffer_size = min(total_ram * 2 // 1000, 4 * 1024 * 1024)  # 使用内存的 0.2%,最大限制为 4MB
    table_open_cache = min(400 + (total_ram // 64), 2000)  # 根据内存动态计算,最大限制为 2000
    thread_cache_size = min(total_ram * 15 // 1000, 100)  # 使用内存的 1.5%,最大限制为 100
    innodb_log_buffer_size = min(total_ram * 5 // 100, 16 * 1024 * 1024)  # 使用内存的 5%,最大限制为 16MB

    # 以字节为单位打印配置
    print(f"MySQL 配置(基于总内存 {total_ram / (1024 * 1024):.2f} MB):")
    print("将以下内容添加到 /etc/mysql/mysql.conf.d/mysqld.cnf 的末尾\n")
    
    print(f"innodb_buffer_pool_size = {innodb_buffer_pool_size}")
    print(f"key_buffer_size = {key_buffer_size}")
    print(f"sort_buffer_size = {sort_buffer_size}")
    print(f"read_rnd_buffer_size = {read_rnd_buffer_size}")
    print(f"tmp_table_size = {tmp_table_size}")
    print(f"max_heap_table_size = {max_heap_table_size}")
    print(f"join_buffer_size = {join_buffer_size}")
    print(f"table_open_cache = {table_open_cache}")
    print(f"thread_cache_size = {thread_cache_size}")
    print(f"innodb_log_buffer_size = {innodb_log_buffer_size}")

    # 打印自定义设置
    print("expire_logs_days = 3")
    print("max_binlog_size = 100M")

if __name__ == "__main__":
    calculate_mysql_settings()

会打印出类似以下的配置:

innodb_buffer_pool_size = 626468044
key_buffer_size = 417645363
sort_buffer_size = 4194304
read_rnd_buffer_size = 524288
tmp_table_size = 67108864
max_heap_table_size = 67108864
join_buffer_size = 4176453
table_open_cache = 2000
thread_cache_size = 100
innodb_log_buffer_size = 16777216
expire_logs_days = 3
max_binlog_size = 100M

添加到MySQL的配置文件:/etc/mysql/mysql.conf.d/mysqld.cnf 然后重启数据库即可:service mysql restart

BASH脚本优化MySQL数据库参数

以下是完成同样功能的BASH脚本。

#!/bin/bash

# 获取总内存大小(以字节为单位)
get_total_ram() {
    # 从 /proc/meminfo 中提取总内存(以 kB 为单位)
    total_ram_kb=$(awk '/^MemTotal:/ {print $2}' /proc/meminfo)
    if [[ -z "$total_ram_kb" ]]; then
        echo 0  # 如果未找到 MemTotal,则返回 0
    else
        echo $((total_ram_kb * 1024))  # 将 kB 转换为字节
    fi
}

# 根据总内存大小计算 MySQL 配置
calculate_mysql_settings() {
    # 获取总内存(以字节为单位)
    total_ram=$(get_total_ram)

    # 计算 MySQL 配置参数
    innodb_buffer_pool_size=$((total_ram * 30 / 100))  # 使用内存的 30%
    key_buffer_size=$(($((total_ram * 20 / 100)) < $((512 * 1024 * 1024)) ? $((total_ram * 20 / 100)) : $((512 * 1024 * 1024))))  # 使用内存的 20%,最大限制为 512MB
    sort_buffer_size=$(($((total_ram * 25 / 1000)) < $((4 * 1024 * 1024)) ? $((total_ram * 25 / 1000)) : $((4 * 1024 * 1024))))  # 使用内存的 0.25%,最大限制为 4MB
    read_rnd_buffer_size=$(($((total_ram * 625 / 100000)) < $((512 * 1024)) ? $((total_ram * 625 / 100000)) : $((512 * 1024))))  # 使用内存的 0.0625%,最大限制为 512KB
    tmp_table_size=$((total_ram * 5 / 100 < 64 * 1024 * 1024 ? total_ram * 5 / 100 : 64 * 1024 * 1024))  # 使用内存的 5%,最大限制为 64MB
    max_heap_table_size=$tmp_table_size  # 临时表大小等于最大堆表大小
    join_buffer_size=$(($((total_ram * 2 / 1000)) < $((4 * 1024 * 1024)) ? $((total_ram * 2 / 1000)) : $((4 * 1024 * 1024))))  # 使用内存的 0.2%,最大限制为 4MB
    table_open_cache=$(($((400 + total_ram / 64)) < 2000 ? $((400 + total_ram / 64)) : 2000))  # 根据内存动态计算,最大限制为 2000
    thread_cache_size=$(($((total_ram * 15 / 1000)) < 100 ? $((total_ram * 15 / 1000)) : 100))  # 使用内存的 1.5%,最大限制为 100
    innodb_log_buffer_size=$(($((total_ram * 5 / 100)) < $((16 * 1024 * 1024)) ? $((total_ram * 5 / 100)) : $((16 * 1024 * 1024))))  # 使用内存的 5%,最大限制为 16MB

    # 打印配置(以字节为单位)
    echo "MySQL 配置(基于总内存 $((total_ram / (1024 * 1024))) MB):"
    echo "将以下内容添加到 /etc/mysql/mysql.conf.d/mysqld.cnf 的末尾"
    echo
    echo "innodb_buffer_pool_size = $innodb_buffer_pool_size"
    echo "key_buffer_size = $key_buffer_size"
    echo "sort_buffer_size = $sort_buffer_size"
    echo "read_rnd_buffer_size = $read_rnd_buffer_size"
    echo "tmp_table_size = $tmp_table_size"
    echo "max_heap_table_size = $max_heap_table_size"
    echo "join_buffer_size = $join_buffer_size"
    echo "table_open_cache = $table_open_cache"
    echo "thread_cache_size = $thread_cache_size"
    echo "innodb_log_buffer_size = $innodb_log_buffer_size"
    echo
    echo "expire_logs_days = 3"  # 日志过期天数设置为 3 天
    echo "max_binlog_size = 100M"  # 最大二进制日志大小设置为 100M
}

# 主函数调用
calculate_mysql_settings

需要注意的是,我在脚本后面加入了一些我自定义的配置,根据需求自行修改即可。在配置文件里,后面定义的会覆盖前面的,这就是为什么要添加到文件尾的原因。

其中最关键的配置 innodb_buffer_pool_size 我设置为使用当前内存的30%,如果服务器只有数据库/博客这个功能,可以适当的提高比例,比如60%-80%。

英文:Python/Bash Script to Print the Optimized Parameters for MySQL Servers

运维/DevOps

本文一共 812 个汉字, 你数一下对不对.
MySQL参数一键配置脚本: 有效提升数据库性能. (AMP 移动加速版本)

扫描二维码,分享本文到微信朋友圈
75a5a60b9cac61e5c8c71a96e17f2d9c MySQL参数一键配置脚本: 有效提升数据库性能 MySQL 学习笔记 数据库 计算机 计算机 运维 运维 DevOps
The post MySQL参数一键配置脚本: 有效提升数据库性能 first appeared on 小赖子的英国生活和资讯.

相关文章:

  1. 步步高学生电脑上 Basic 编程语言 peek 用法示例 步步高学生电脑 是8位FC机的经典之作.它上面的BASIC有三个版本 1.0, 2.0 和 2.1 2.1 版本有个在线帮助,实际上是 help.cmd 1.0 是用 Esc 键退回到 DOS 的,...
  2. 一张图告诉你北京的雾霾有多严重 一北京的朋友朋友圈发的: 左上为全新口罩;右上为全新口罩本周一到周五每天室外戴20分钟左右;左下为全新口罩今早室外+公交车戴一个半小时;右下为全新口罩今早开车戴一小时左右. 还有这图 空气污染 – 红色的是严重的.中国,尤其是华北地区,是全球最红的地区,没有”之一”. 本文一共 113 个汉字, 你数一下对不对. 一张图告诉你北京的雾霾有多严重. (AMP 移动加速版本) 赞赏我的几个理由. ¥...
  3. 你给SteemIt中文微信群拖后腿了么? 这年头不缺算法, 就缺数据. 这两天花了很多时间在整API上, 整完之后自己用了一下还觉得真是挺方便的. 今天就突然想看一看自己是否给大家拖后腿了, 于是调用每日中文区微信群排行榜单的API, 刷刷拿着 NodeJs 练手: 1 2 3 4 5 6...
  4. 穷举算法的应用 – 去除EXCEL文件中的保护 EXCEL 是可以用密码来保护的. 比如 这个EXCEL 就用了密码保护. 打开EXCEL文件 你会注意到 无法编辑 无法查看宏(VBA)的代码. 去除保护很简单 第一步先编辑宏 VBA 把下面的VBA代码拷贝到VBA编辑器里 并按下F5运行 1...
  5. 谈谈 Utopian 成立公司 就在刚刚 Utopian 的老板 @elear 在 帖子和 discord 上宣布在 意大利成立 Utopian 公司. 可喜可贺! 这开始只是 Steem 上的一个小项目,...
  6. 步步高多媒体学生电脑 汇编程序设计 – 1 英文同步 90年代后期步步高生产的软驱一号(又称步步高多媒体学生电脑)和98型学生电脑都带了软驱,一按电源件, 都从软盘启动(98型可以从内置的电子盘启动) 步步高提供了直接在学习机上写汇编开发的工具 BASM. BASM 可以用来写 6502 汇编,并可以编译成 CMD 小型可执行程序 不支持 EXC 程序. CMD...
  7. 按揭贷款(房贷,车贷) 每月还贷计算器 去年给银行借了17万英镑 买了20万7500英镑的房子, 25年还清. 前2年是定率 Fix Rate 的合同 (年利率2.49%). 每个月大概是还 700多英镑. 有很多种还贷的计算方式, 定率/每月固定 是比较常用的. 简单来说就是 每个月交的钱是...
  8. 舍得给员工培训的公司是好公司 最近出差比较多, 很多人问我都干嘛去. 各种开会, 各种培训. 公司从剑桥一个软件公司请了一个专业的软件专家来做软件工程上的顾问. 我是 R&D 研发经理, 所以很自然的就要和他经常讨论, 然后目标是把当前公司的软件开发流程给完善, 提高, 把以前做的不对的得整对了. 培训的内容很多, 让我觉得以前公司完全就是在瞎搞, 什么...
❌
❌