MySQL 8.0 新版专用参数优化实战:吃透新特性,榨干数据库极限性能

news2026/4/10 18:56:03
本文原创首发 CSDN聚焦 MySQL 8.0 专属优化特性拒绝照搬 5.7 通用配置所有参数均经过生产环境验证高并发场景实测 TPS 提升 30%主从延迟降至毫秒级。摘要很多 DBA 和运维同学升级 MySQL 8.0 后直接照搬 5.7 的 my.cnf 配置结果不仅没享受到 8.0 内核重构的性能红利反而出现性能下降、启动报错、主从延迟飙升等问题。本文只聚焦 MySQL 8.0.30 LTS 最新稳定版新增的专属优化参数覆盖 InnoDB 存储引擎、优化器 执行器、连接管理、资源管控、日志系统五大核心模块每个参数都附带原理详解、生产级配置、踩坑避坑指南看完即可直接落地真正榨干 MySQL 8.0 的极限性能。目录前言别再用 5.7 的配置拖累 MySQL 8.0 的性能优化前提版本基线与环境确认模块一InnoDB 存储引擎 8.0 专属核心优化性能提升核心模块二优化器 执行器 8.0 专属参数SQL 性能翻倍模块三连接管理 线程模型 8.0 专属优化扛住百万并发模块四资源管控 负载隔离8.0 独有特性榨干多核性能模块五日志系统 8.0 专属优化兼顾性能与数据安全生产环境一键优化配置模板OLTP/OLAP 双场景优化效果验证3 步确认性能提升避坑指南MySQL 8.0 参数优化的 7 大致命误区总结1. 前言别再用 5.7 的配置拖累 MySQL 8.0 的性能MySQL 8.0 堪称发展史上的里程碑版本官方重构了 70% 的内核代码在事务处理、查询优化、并发控制等方面做了革命性升级实测正确配置后 OLTP 场景性能较 5.7 最高提升 3 倍。但现实中80% 以上的用户升级后直接沿用 5.7 的配置文件导致大量新特性无法生效甚至触发废弃参数的兼容性问题最终性能平均下降 40%。本文的核心目标就是帮你彻底跳出 5.7 的优化思维用 8.0 专属的参数和特性真正发挥数据库的极限性能。本文核心原则只讲 8.0 新增、5.7 完全没有的专属参数网上泛滥的通用参数如 innodb_buffer_pool_size仅做适配性说明不做冗余讲解。2. 优化前提版本基线与环境确认2.1 版本基线本文所有参数均基于MySQL 8.0.30 LTS 及以上最新稳定版2026 年最新稳定版为 8.0.37大量核心参数如 innodb_redo_log_capacity是 8.0.30 之后才引入的低版本不支持。版本确认命令SELECT VERSION();2.2 环境与优化原则本文配置基于 Linux x86_64 架构物理机 / 云服务器独占部署容器化 / 多实例部署会有特殊说明请勿直接套用。优化铁律先理解原理再修改配置先测试验证后落地生产杜绝盲目调参。3. 模块一InnoDB 存储引擎 8.0 专属核心优化InnoDB 是 MySQL 性能的核心8.0 对 InnoDB 做了深度重构新增了多个关键优化参数是性能提升的重中之重。3.1 innodb_redo_log_capacity8.0.30 引入核心中的核心官方定位彻底替代废弃的innodb_log_file_size和innodb_log_files_in_group统一管理 redo log 总容量支持在线动态调整解决了老版本 redo log 配置不当导致的 checkpoint 频繁、性能抖动问题。核心原理8.0.30 之后InnoDB 会自动维护 32 个 redo log 文件总容量由该参数统一控制自动调整文件大小和刷盘策略无需手动拆分多个文件。高并发写入场景下合理的容量可以大幅减少 checkpoint 频率降低 IO 等待提升写入吞吐量。生产级配置建议场景配置建议独占物理机 / 云服务器 OLTP 场景物理内存的 10%-20%上限不超过 128G下限不低于 2G示例128G 内存服务器 →innodb_redo_log_capacity 16G低写入 OLAP / 报表场景4G-8G 即可避坑提示8.0.30 版本绝对不要再配置innodb_log_file_size和innodb_log_files_in_group否则会触发警告配置完全不生效redo log 会使用默认 100M导致写入性能暴跌 50% 以上。该参数支持在线动态调整无需重启SET GLOBAL innodb_redo_log_capacity 16*1024*1024*1024;调整时确保磁盘空闲空间大于设置的容量避免磁盘打满。3.2 innodb_dedicated_server8.0.14 引入懒人一键优化神器官方定位专为独占服务器部署的 MySQL 设计自动优化 InnoDB 核心内存、IO、刷盘参数无需手动调参即可获得 80% 以上的最优性能。核心原理开启后MySQL 会自动根据服务器物理内存大小智能配置核心参数innodb_buffer_pool_size1G 内存设为 50%1G-4G 设为 75%4G 设为 80%innodb_redo_log_capacity自动匹配内存大小最高上限 128Ginnodb_flush_method自动设置为 O_DIRECT_NO_FSYNCinnodb_log_buffer_size根据写入负载自动优化生产级配置建议innodb_dedicated_server ON避坑提示容器化部署、多实例部署、服务器上有其他业务如 Java 应用的场景绝对禁止开启否则 MySQL 会按宿主机总内存分配资源导致内存溢出 OOM。显式设置的参数优先级高于自动配置如果你手动设置了 buffer pool 大小会覆盖自动配置的值。3.3 innodb_doublewrite 系列参数8.0.20 引入性能 安全双提升官方定位8.0.20 彻底重构了双写缓冲DBLWR不再依赖系统表空间支持独立配置路径、大小、批量写入参数解决了老版本双写缓冲的锁竞争问题在保证数据安全的前提下大幅提升写入性能。核心参数详解参数名核心作用innodb_doublewrite_dir双写文件独立存放路径建议与数据文件分离部署在高性能 SSD 上减少 IO 竞争innodb_doublewrite_pages每个线程双写页的最大数量默认值 48.4.0 修正为 1288.0 版本需手动优化innodb_doublewrite_batch_size双写批量写入页数控制单次 IO 的写入量提升顺序写效率innodb_doublewrite_files双写文件的数量高并发场景建议增大生产级配置建议innodb_doublewrite_dir /fast_ssd/mysql/dblwr/ innodb_doublewrite_pages 128 innodb_doublewrite_batch_size 64 innodb_doublewrite_files 4避坑提示不要盲目关闭双写缓冲除非你 100% 确认存储系统支持 16K 原子写否则服务器崩溃会导致数据页损坏无法恢复造成数据丢失。该系列参数仅 8.0.20 版本支持低版本配置会导致启动失败。3.4 其他核心 InnoDB 专属参数参数名引入版本核心作用生产级配置innodb_spin_wait_pause_multiplier8.0.24多核 CPU 自旋锁精细化优化减少高并发下的 CPU 空转16-32 核设为 6432 核以上设为 128innodb_buffer_pool_in_core_file8.0.14控制缓冲池是否写入 core 文件关闭后 core 文件大小从百 G 降至几十 MB避免故障排查时磁盘打满OFF4. 模块二优化器 执行器 8.0 专属参数SQL 性能翻倍8.0 重构了查询优化器新增了多个革命性的查询优化特性配合专属参数调整复杂 SQL 性能可提升 10 倍以上。4.1 derived_condition_pushdown8.0.22 引入子查询性能革命性优化官方定位派生表条件下推优化解决了老版本子查询外层条件无法下推到内层派生表的问题子查询性能最高提升 10 倍。核心原理开启后优化器会将外层查询的 WHERE 条件自动下推到派生表子查询内部提前过滤数据大幅减少临时表的数据量避免全表扫描。尤其适合大量使用子查询的报表、数据分析场景。生产级配置建议-- 全局开启8.0.24版本默认开启低版本需手动设置 SET GLOBAL optimizer_switch derived_condition_pushdownon;避坑提示如果子查询包含用户变量、聚合函数、LIMIT 子句该优化不会生效需手动改写 SQL。4.2 internal_tmp_mem_storage_engine8.0.16 引入临时表引擎性能飞跃官方定位替代老版本的tmp_table_engine新增TempTable 内存引擎专门优化 GROUP BY、ORDER BY 等操作的临时表性能较老的 MEMORY 引擎性能提升 2 倍以上。核心原理TempTable 引擎支持变长字段存储内存利用率远高于固定长度的 MEMORY 引擎同时支持哈希索引和内存映射文件MMAP作为内存溢出的中间层避免临时表直接落盘到 InnoDB大幅降低 IO 开销。配套核心参数参数名核心作用temptable_max_ramTempTable 引擎最大可用内存默认 1Gtemptable_max_mmap内存溢出后MMAP 文件的最大大小避免磁盘打满temptable_use_mmap是否启用 MMAP 作为内存溢出的中间层生产级配置建议internal_tmp_mem_storage_engine TempTable temptable_max_ram 4G temptable_max_mmap 8G temptable_use_mmap ON避坑提示MySQL 8.0 彻底移除了 MyISAM 作为临时表引擎的支持不要再尝试配置 MyISAM会直接报错。temptable_max_ram不要设置超过物理内存的 20%否则会导致内存溢出 OOM。4.3 其他优化器专属参数参数名引入版本核心作用生产级配置hash_join_multiblock_read_factor8.0.23优化 Hash Join 的多块读性能大表 JOIN 场景吞吐量翻倍OLAP 场景设为 64-128OLTP 场景保持默认optimizer_use_invisible_indexes8.0.23控制优化器是否使用不可见索引实现零风险线上索引调优全局保持 OFF会话测试时临时开启5. 模块三连接管理 线程模型 8.0 专属优化扛住百万并发8.0 对连接处理和线程池做了深度优化解决了老版本高并发连接下的惊群、锁竞争问题轻松扛住数十万级并发连接。5.1 thread_pool_dedicated_listener8.0.19 引入线程池惊群问题终极解决官方定位线程池专用监听器彻底解决了老版本线程池的惊群问题高并发短连接场景下TPS 提升 30%CPU 使用率降低 20%。核心原理老版本线程池所有工作线程都监听新连接高并发下会出现惊群效应大量 CPU 浪费在锁竞争上开启后单独的监听器线程负责接收新连接分配给空闲的工作线程彻底解决惊群问题大幅提升连接处理效率。生产级配置建议# 启用线程池模式 thread_handling pool-of-threads # 开启专用监听器 thread_pool_dedicated_listener ON # 线程池大小建议等于CPU核心数 thread_pool_size 16 # 线程停滞阈值短连接场景调低至20ms thread_pool_stall_limit 20避坑提示MySQL 社区版默认不包含线程池插件需先确认插件已安装SELECT * FROM information_schema.plugins WHERE plugin_name thread_pool;长连接为主的场景如 Java 应用连接池无需开启线程池保持默认的one-thread-per-connection即可否则会增加上下文切换开销。5.2 其他连接管理专属参数表格参数名引入版本核心作用生产级配置disable_tcp_slow_start8.0.14禁用 TCP 慢启动长连接场景网络吞吐量提升 20%减少查询延迟长连接场景设为 ON短连接场景保持 OFFthread_pool_max_transactions_limit8.0.28线程池级别的事务上限管控避免突发流量打满数据库实现流量削峰根据服务器性能设置如 100006. 模块四资源管控 负载隔离8.0 独有特性榨干多核性能资源组Resource Groups是 MySQL 8.0 新增的杀手级特性5.7 完全不支持核心是实现 CPU 核心绑定、线程优先级管控、业务负载隔离彻底解决 “一核有难多核围观” 的问题。6.1 核心开关与原理总开关参数thread_resource_group_enabled8.0.16 引入默认开启核心原理资源组分为USER用户线程和SYSTEM系统后台线程两种类型可绑定指定的 CPU 核心设置线程优先级实现不同业务负载的 CPU 资源隔离避免非核心业务抢占核心业务的 CPU 资源。6.2 生产级优化实战方案场景32 核 CPU 服务器混合 OLTP 核心交易 OLAP 报表查询避免报表查询打满 CPU 影响交易稳定性。步骤 1创建专属资源组-- 1. 高优先级OLTP核心交易资源组绑定0-15核最高优先级 CREATE RESOURCE GROUP oltp_core TYPE USER VCPU 0-15 THREAD_PRIORITY -10; -- 2. 低优先级OLAP报表资源组绑定16-31核低优先级 CREATE RESOURCE GROUP olap_report TYPE USER VCPU 16-31 THREAD_PRIORITY 10; -- 3. InnoDB后台线程资源组绑定16-31核系统最高优先级避免与用户线程竞争 CREATE RESOURCE GROUP innodb_bg TYPE SYSTEM VCPU 16-31 THREAD_PRIORITY -20;步骤 2分配资源组-- 核心交易用户绑定OLTP资源组 ALTER USER trade_user% RESOURCE GROUP oltp_core; -- 报表用户绑定OLAP资源组 ALTER USER report_user% RESOURCE GROUP olap_report; -- 后台刷脏线程绑定专属资源组需先查询thread_id SET RESOURCE GROUP innodb_bg FOR thread_id;6.3 避坑提示资源组仅支持 Linux 系统Windows 系统不支持。优先级范围SYSTEM 类型为 - 20~0USER 类型为 0~19数值越小优先级越高。必须拥有RESOURCE_GROUP_ADMIN权限才能操作资源组。7. 模块五日志系统 8.0 专属优化兼顾性能与数据安全8.0 对 binlog、慢日志、错误日志系统做了全面优化在保证数据安全和可观测性的前提下大幅降低日志写入的性能开销。7.1 binlog_transaction_dependency_tracking8.0.2 引入主从复制革命性优化官方定位基于 WriteSet 的事务依赖跟踪彻底解决了老版本主从复制延迟的问题即使主库串行提交的事务只要无行冲突从库也可以并行回放主从延迟从秒级降至毫秒级。核心原理5.7 仅支持COMMIT_ORDER模式只有主库并行提交的事务从库才能并行回放并行度完全依赖主库的并发量。8.0 新增WRITESET模式每个事务提交时生成写集合WriteSet只要两个事务的写集合无交集从库就可以并行回放并行度提升 10 倍以上。生产级配置建议# 主库核心配置 binlog_transaction_dependency_tracking WRITESET transaction_write_set_extraction XXHASH64 binlog_transaction_dependency_history_size 100000 # 从库配套配置 replica_parallel_type LOGICAL_CLOCK replica_parallel_workers CPU核心数 replica_preserve_commit_order ON避坑提示无主键的表无法生成 WriteSet该优化完全不生效必须确保所有表都设置主键。7.2 其他日志系统专属参数参数名引入版本核心作用生产级配置binlog_expire_logs_auto_purge8.0.29替代废弃的expire_logs_days支持按时间 / 大小双重规则自动清理 binlog避免集中清理导致的 IO 抖动ON配套binlog_expire_logs_seconds6048007 天过期log_throttle_queries_not_using_indexes8.0.11限制未使用索引的查询的慢日志输出频率避免慢日志风暴打满磁盘60每分钟最多输出 60 条8. 生产环境一键优化配置模板以下模板基于MySQL 8.0.30 LTS 版本Linux x86_64 架构独占服务器部署容器化 / 多实例场景需调整内存相关参数。模板一OLTP 高并发交易场景电商、金融、核心业务适用场景高并发读写、事务响应时间要求高、数据一致性要求高服务器配置16C/64G/SSD[mysqld] # 基础配置 server_id 1001 port 3306 datadir /data/mysql/data socket /data/mysql/mysql.sock pid_file /data/mysql/mysql.pid user mysql default_time_zone 8:00 # -------------------------- # 8.0 专属InnoDB核心优化 # -------------------------- innodb_dedicated_server ON innodb_redo_log_capacity 12G innodb_doublewrite_dir /fast_ssd/mysql/dblwr/ innodb_doublewrite_pages 128 innodb_doublewrite_batch_size 64 innodb_doublewrite_files 4 innodb_spin_wait_pause_multiplier 64 innodb_buffer_pool_in_core_file OFF # -------------------------- # 8.0 专属优化器配置 # -------------------------- optimizer_switch derived_condition_pushdownon,hash_joinon hash_join_multiblock_read_factor 64 internal_tmp_mem_storage_engine TempTable temptable_max_ram 4G temptable_max_mmap 8G # -------------------------- # 8.0 专属连接管理优化 # -------------------------- thread_handling one-thread-per-connection disable_tcp_slow_start ON max_connections 2000 # -------------------------- # 8.0 专属日志复制优化 # -------------------------- binlog_transaction_dependency_tracking WRITESET transaction_write_set_extraction XXHASH64 binlog_transaction_dependency_history_size 100000 binlog_expire_logs_seconds 604800 binlog_expire_logs_auto_purge ON max_binlog_size 1G log_slow_extra ON log_throttle_queries_not_using_indexes 60 long_query_time 1 slow_query_log ON slow_query_log_file /data/mysql/logs/slow.log # -------------------------- # 8.0 专属资源组配置 # -------------------------- thread_resource_group_enabled ON # 安全配置 sql_mode STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO super_read_only OFF模板二OLAP 数据分析场景报表、数仓、批量数据处理适用场景大数据量复杂查询、批量写入、CPU 密集型操作服务器配置32C/128G/SSD[mysqld] # 基础配置 server_id 1002 port 3306 datadir /data/mysql/data socket /data/mysql/mysql.sock pid_file /data/mysql/mysql.pid user mysql default_time_zone 8:00 # -------------------------- # 8.0 专属InnoDB核心优化 # -------------------------- innodb_dedicated_server ON innodb_redo_log_capacity 24G innodb_doublewrite_dir /fast_ssd/mysql/dblwr/ innodb_doublewrite_pages 256 innodb_doublewrite_batch_size 128 innodb_doublewrite_files 8 innodb_spin_wait_pause_multiplier 128 innodb_buffer_pool_in_core_file OFF # -------------------------- # 8.0 专属优化器配置 # -------------------------- optimizer_switch derived_condition_pushdownon,hash_joinon,skip_scanon hash_join_multiblock_read_factor 128 internal_tmp_mem_storage_engine TempTable temptable_max_ram 16G temptable_max_mmap 32G temptable_use_mmap ON # -------------------------- # 8.0 专属线程池优化 # -------------------------- thread_handling pool-of-threads thread_pool_dedicated_listener ON thread_pool_size 32 thread_pool_stall_limit 100 thread_pool_max_transactions_limit 5000 # -------------------------- # 8.0 专属日志配置 # -------------------------- binlog_expire_logs_seconds 259200 binlog_expire_logs_auto_purge ON max_binlog_size 4G log_slow_extra ON log_throttle_queries_not_using_indexes 100 long_query_time 5 slow_query_log ON slow_query_log_file /data/mysql/logs/slow.log # -------------------------- # 8.0 专属资源组配置 # -------------------------- thread_resource_group_enabled ON9. 优化效果验证3 步确认性能提升9.1 参数生效验证查看参数是否正确加载SHOW VARIABLES LIKE 参数名;查看错误日志确认无警告、无报错grep -i warning /data/mysql/logs/error.log9.2 性能基准测试推荐使用 sysbench、TPCC-MySQL 进行基准测试核心对比指标TPS、QPS、95% 响应时间、CPU 使用率、IO 等待时间。sysbench OLTP 读写测试示例# 准备测试数据 sysbench oltp_read_write --mysql-host127.0.0.1 --mysql-port3306 --mysql-userroot --mysql-passwordxxx --mysql-dbtest --tables10 --table-size1000000 prepare # 执行性能测试 sysbench oltp_read_write --mysql-host127.0.0.1 --mysql-port3306 --mysql-userroot --mysql-passwordxxx --mysql-dbtest --tables10 --table-size1000000 --threads64 --time300 run9.3 生产环境监控验证核心监控指标对比优化前后的变化事务吞吐量TPS、QPS响应时间平均事务响应时间、慢查询数量资源使用率CPU 使用率、IO 等待、内存使用率主从延迟Seconds_Behind_Master10. 避坑指南MySQL 8.0 参数优化的 7 大致命误区误区 1直接照搬 MySQL 5.7 的 my.cnf 配置后果大量参数在 8.0 已被废弃导致启动报错、性能暴跌比如query_cache、innodb_log_file_size等。正确做法彻底重构配置文件优先使用 8.0 新增的专属参数。误区 28.0.30 版本依然配置老的 redo log 参数后果配置不生效redo log 使用默认 100M频繁触发 checkpoint写入性能暴跌。正确做法统一使用innodb_redo_log_capacity删除老的两个参数。误区 3容器化 / 多实例场景开启 innodb_dedicated_server后果MySQL 按宿主机总内存分配资源导致容器内存超限被 OOM kill。正确做法手动配置内存相关参数禁止开启该参数。误区 4盲目开启线程池不区分业务场景后果长连接场景开启线程池反而增加上下文切换开销性能下降。正确做法短连接高并发场景开启线程池长连接场景保持默认模式。误区 5为了性能关闭双写缓冲后果服务器断电 / 崩溃时数据页损坏无法恢复造成数据丢失。正确做法使用 8.0 重构后的双写缓冲优化参数兼顾性能与安全。误区 6WriteSet 并行复制不设置主键后果无主键的表无法生成 WriteSet并行复制优化完全不生效主从延迟依然很高。正确做法所有表必须设置主键。误区 7盲目调大所有参数认为越大性能越好后果redo log 容量过大导致崩溃恢复时间变长线程池过大导致上下文切换飙升。正确做法根据业务场景和服务器配置合理设置先理解原理再调参。11. 总结MySQL 8.0 不仅仅是 5.7 的简单升级而是内核重构的里程碑版本。很多人升级后性能没有提升核心原因就是没有拥抱新特性依然守着 5.7 的老经验、老配置。本文梳理的所有参数都是 MySQL 8.0 专属的核心优化点覆盖了数据库性能优化的全链路。按照本文的方案配置实测高并发 OLTP 场景 TPS 提升 30%主从延迟降至毫秒级OLAP 场景复杂查询性能提升 2-10 倍。最后再次强调数据库优化没有银弹所有参数都需要结合你的业务场景、服务器配置先在测试环境充分验证再逐步落地到生产环境。原创不易如果本文对你有帮助欢迎点赞、收藏、关注后续会持续分享 MySQL 8.0 实战优化、运维排坑、高可用架构等内容。有任何问题欢迎在评论区留言交流我会一一回复。本文标签#MySQL 8.0 #数据库优化 #InnoDB #性能调优 #DBA 运维 #MySQL 实战

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2499504.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

SpringBoot-17-MyBatis动态SQL标签之常用标签

文章目录 1 代码1.1 实体User.java1.2 接口UserMapper.java1.3 映射UserMapper.xml1.3.1 标签if1.3.2 标签if和where1.3.3 标签choose和when和otherwise1.4 UserController.java2 常用动态SQL标签2.1 标签set2.1.1 UserMapper.java2.1.2 UserMapper.xml2.1.3 UserController.ja…

wordpress后台更新后 前端没变化的解决方法

使用siteground主机的wordpress网站,会出现更新了网站内容和修改了php模板文件、js文件、css文件、图片文件后,网站没有变化的情况。 不熟悉siteground主机的新手,遇到这个问题,就很抓狂,明明是哪都没操作错误&#x…

网络编程(Modbus进阶)

思维导图 Modbus RTU(先学一点理论) 概念 Modbus RTU 是工业自动化领域 最广泛应用的串行通信协议,由 Modicon 公司(现施耐德电气)于 1979 年推出。它以 高效率、强健性、易实现的特点成为工业控制系统的通信标准。 包…

UE5 学习系列(二)用户操作界面及介绍

这篇博客是 UE5 学习系列博客的第二篇,在第一篇的基础上展开这篇内容。博客参考的 B 站视频资料和第一篇的链接如下: 【Note】:如果你已经完成安装等操作,可以只执行第一篇博客中 2. 新建一个空白游戏项目 章节操作,重…

IDEA运行Tomcat出现乱码问题解决汇总

最近正值期末周,有很多同学在写期末Java web作业时,运行tomcat出现乱码问题,经过多次解决与研究,我做了如下整理: 原因: IDEA本身编码与tomcat的编码与Windows编码不同导致,Windows 系统控制台…

利用最小二乘法找圆心和半径

#include <iostream> #include <vector> #include <cmath> #include <Eigen/Dense> // 需安装Eigen库用于矩阵运算 // 定义点结构 struct Point { double x, y; Point(double x_, double y_) : x(x_), y(y_) {} }; // 最小二乘法求圆心和半径 …

使用docker在3台服务器上搭建基于redis 6.x的一主两从三台均是哨兵模式

一、环境及版本说明 如果服务器已经安装了docker,则忽略此步骤,如果没有安装,则可以按照一下方式安装: 1. 在线安装(有互联网环境): 请看我这篇文章 传送阵>> 点我查看 2. 离线安装(内网环境):请看我这篇文章 传送阵>> 点我查看 说明&#xff1a;假设每台服务器已…

XML Group端口详解

在XML数据映射过程中&#xff0c;经常需要对数据进行分组聚合操作。例如&#xff0c;当处理包含多个物料明细的XML文件时&#xff0c;可能需要将相同物料号的明细归为一组&#xff0c;或对相同物料号的数量进行求和计算。传统实现方式通常需要编写脚本代码&#xff0c;增加了开…

LBE-LEX系列工业语音播放器|预警播报器|喇叭蜂鸣器的上位机配置操作说明

LBE-LEX系列工业语音播放器|预警播报器|喇叭蜂鸣器专为工业环境精心打造&#xff0c;完美适配AGV和无人叉车。同时&#xff0c;集成以太网与语音合成技术&#xff0c;为各类高级系统&#xff08;如MES、调度系统、库位管理、立库等&#xff09;提供高效便捷的语音交互体验。 L…

(LeetCode 每日一题) 3442. 奇偶频次间的最大差值 I (哈希、字符串)

题目&#xff1a;3442. 奇偶频次间的最大差值 I 思路 &#xff1a;哈希&#xff0c;时间复杂度0(n)。 用哈希表来记录每个字符串中字符的分布情况&#xff0c;哈希表这里用数组即可实现。 C版本&#xff1a; class Solution { public:int maxDifference(string s) {int a[26]…

【大模型RAG】拍照搜题技术架构速览:三层管道、两级检索、兜底大模型

摘要 拍照搜题系统采用“三层管道&#xff08;多模态 OCR → 语义检索 → 答案渲染&#xff09;、两级检索&#xff08;倒排 BM25 向量 HNSW&#xff09;并以大语言模型兜底”的整体框架&#xff1a; 多模态 OCR 层 将题目图片经过超分、去噪、倾斜校正后&#xff0c;分别用…

【Axure高保真原型】引导弹窗

今天和大家中分享引导弹窗的原型模板&#xff0c;载入页面后&#xff0c;会显示引导弹窗&#xff0c;适用于引导用户使用页面&#xff0c;点击完成后&#xff0c;会显示下一个引导弹窗&#xff0c;直至最后一个引导弹窗完成后进入首页。具体效果可以点击下方视频观看或打开下方…

接口测试中缓存处理策略

在接口测试中&#xff0c;缓存处理策略是一个关键环节&#xff0c;直接影响测试结果的准确性和可靠性。合理的缓存处理策略能够确保测试环境的一致性&#xff0c;避免因缓存数据导致的测试偏差。以下是接口测试中常见的缓存处理策略及其详细说明&#xff1a; 一、缓存处理的核…

龙虎榜——20250610

上证指数放量收阴线&#xff0c;个股多数下跌&#xff0c;盘中受消息影响大幅波动。 深证指数放量收阴线形成顶分型&#xff0c;指数短线有调整的需求&#xff0c;大概需要一两天。 2025年6月10日龙虎榜行业方向分析 1. 金融科技 代表标的&#xff1a;御银股份、雄帝科技 驱动…

观成科技:隐蔽隧道工具Ligolo-ng加密流量分析

1.工具介绍 Ligolo-ng是一款由go编写的高效隧道工具&#xff0c;该工具基于TUN接口实现其功能&#xff0c;利用反向TCP/TLS连接建立一条隐蔽的通信信道&#xff0c;支持使用Let’s Encrypt自动生成证书。Ligolo-ng的通信隐蔽性体现在其支持多种连接方式&#xff0c;适应复杂网…

铭豹扩展坞 USB转网口 突然无法识别解决方法

当 USB 转网口扩展坞在一台笔记本上无法识别,但在其他电脑上正常工作时,问题通常出在笔记本自身或其与扩展坞的兼容性上。以下是系统化的定位思路和排查步骤,帮助你快速找到故障原因: 背景: 一个M-pard(铭豹)扩展坞的网卡突然无法识别了,扩展出来的三个USB接口正常。…

未来机器人的大脑:如何用神经网络模拟器实现更智能的决策?

编辑&#xff1a;陈萍萍的公主一点人工一点智能 未来机器人的大脑&#xff1a;如何用神经网络模拟器实现更智能的决策&#xff1f;RWM通过双自回归机制有效解决了复合误差、部分可观测性和随机动力学等关键挑战&#xff0c;在不依赖领域特定归纳偏见的条件下实现了卓越的预测准…

Linux应用开发之网络套接字编程(实例篇)

服务端与客户端单连接 服务端代码 #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <arpa/inet.h> #include <pthread.h> …

华为云AI开发平台ModelArts

华为云ModelArts&#xff1a;重塑AI开发流程的“智能引擎”与“创新加速器”&#xff01; 在人工智能浪潮席卷全球的2025年&#xff0c;企业拥抱AI的意愿空前高涨&#xff0c;但技术门槛高、流程复杂、资源投入巨大的现实&#xff0c;却让许多创新构想止步于实验室。数据科学家…

深度学习在微纳光子学中的应用

深度学习在微纳光子学中的主要应用方向 深度学习与微纳光子学的结合主要集中在以下几个方向&#xff1a; 逆向设计 通过神经网络快速预测微纳结构的光学响应&#xff0c;替代传统耗时的数值模拟方法。例如设计超表面、光子晶体等结构。 特征提取与优化 从复杂的光学数据中自…