资讯频道 → 数据库
阅读更多

6顶
0踩

数据库

转载新闻 淘宝内部分享：MySQL & MariaDB性能优化

2015-01-21 10:55 by 副主编 mengyidan1988 评论(0) 有8559人浏览
mysql MariaDB
编者按：MySQL是目前使用最多的开源数据库，但是MySQL数据库的默认设置性能非常的差，必须进行不断的优化，而优化是一个复杂的任务，本文描述淘宝数据库团队针对MySQL数据库Metadata Lock子系统的优化，hash_scan 算法的实现解析的性能优化，TokuDB·版本优化，以及MariaDB的性能优化。本文来自淘宝团队内部经验分享。

往期文章：淘宝内部分享：怎么跳出MySQL的10个大坑
MySQL·　5.7优化·Metadata Lock子系统的优化

背景

引入MDL锁的目的，最初是为了解决著名的bug#989，在MySQL 5.1及之前的版本，事务执行过程中并不维护涉及到的所有表的Metatdata 锁，极易出现复制中断，例如如下执行序列：
引用
Session 1: BEGIN;
Session 1: INSERT INTO t1 VALUES (1);
Session 2: Drop table t1; --------SQL写入BINLOG
Session 1: COMMIT; -----事务写入BINLOG

在备库重放 binlog时，会先执行DROP TABLE，再INSERT数据，从而导致复制中断。

在MySQL 5.5版本里，引入了MDL, 在事务过程中涉及到的所有表的MDL锁，直到事务结束才释放。这意味着上述序列的DROP TABLE 操作将被Session 1阻塞住直到其提交。

不过用过5.5的人都知道，MDL实在是个让人讨厌的东西，相信不少人肯定遇到过在使用mysqldump做逻辑备份时，由于需要执行FLUSH TABLES WITH READ LOCK (以下用FTWRL缩写代替)来获取全局GLOBAL的MDL锁，因此经常可以看到“wait for global read lock”之类的信息。如果备库存在大查询，或者复制线程正在执行比较漫长的DDL，并且FTWRL被block住，那么随后的QUERY都会被block住，导致业务不可用引发故障。

为了解决这个问题，Facebook为MySQL增加新的接口替换掉FTWRL 只创建一个read view ，并返回与read view一致的binlog位点；另外Percona Server也实现了一种类似的办法来绕过FTWRL，具体点击文档连接以及percona的博客，不展开阐述。

MDL解决了bug#989，却引入了一个新的热点，所有的MDL锁对象被维护在一个hash对象中；对于热点，最正常的想法当然是对其进行分区来分散热点，不过这也是Facebook的大神Mark Callaghan在report了bug#66473后才加入的，当时Mark观察到MDL_map::mutex的锁竞争非常高，进而推动官方改变。因此在MySQL 5.6.8及之后的版本中，引入了新参数metadata_locks_hash_instances来控制对mdl hash的分区数(Rev:4350)；

不过故事还没结束，后面的测试又发现哈希函数有问题，somedb. someprefix1 … .somedb .someprefix8 的hash key值相同，都被hash到同一个桶下面了，相当于hash分区没生效。这属于hash算法的问题，喜欢考古的同学可以阅读下bug#66473后面Dmitry Lenev的分析。

Mark进一步的测试发现Innodb的hash计算算法比my_hash_sort_bin要更高效， Oracle的开发人员重开了个bug#68487来跟踪该问题，并在MySQL5.6.15对hash key计算函数进行优化，包括fix 上面说的hash计算问题(Rev:5459)，使用MurmurHash3算法来计算mdl key的hash值。
MySQL 5.7 对MDL锁的优化

在MySQL 5.7里对MDL子系统做了更为彻底的优化。主要从以下几点出发：

第一，尽管对MDL HASH进行了分区，但由于是以表名+库名的方式作为key值进行分区，如果查询或者DML都集中在同一张表上，就会hash到相同的分区，引起明显的MDL HASH上的锁竞争。

针对这一点，引入了LOCK-FREE的HASH来存储MDL_lock，LF_HASH无锁算法基于论文"Split-Ordered Lists: Lock-Free Extensible Hash Tables"，实现还比较复杂。 注：实际上LF_HASH很早就被应用于Performance Schema，算是比较成熟的代码模块。由于引入了LF_HASH，MDL HASH分区特性自然直接被废除了 。对应WL#7305， PATCH(Rev:7249)

第二，从广泛使用的实际场景来看，DML/SELECT相比DDL等高级别MDL锁类型，是更为普遍的，因此可以针对性的降低DML和SELECT操作的MDL开销。

为了实现对DML/SELECT的快速加锁，使用了类似LOCK-WORD的加锁方式，称之为FAST-PATH，如果FAST-PATH加锁失败，则走SLOW-PATH来进行加锁。

每个MDL锁对象（MDL_lock）都维持了一个long long类型的状态值来标示当前的加锁状态，变量名为MDL_lock::m_fast_path_state 举个简单的例子：（初始在sbtest1表上对应MDL_lock::m_fast_path_state值为0）

引用
Session 1: BEGIN;
Session 1: SELECT * FROM sbtest1 WHERE id =1; //m_fast_path_state = 1048576, MDL ticket 不加MDL_lock::m_granted队列
Session 2: BEGIN;
Session 2: SELECT * FROM sbtest1 WHERE id =2; //m_fast_path_state=1048576+1048576=2097152，同上，走FAST PATH
Session 3: ALTER TABLE sbtest1 ENGINE = INNODB; //DDL请求加的MDL_SHARED_UPGRADABLE类型锁被视为unobtrusive lock，可以认为这个是比上述SQL的MDL锁级别更高的锁，并且不相容，因此被强制走slow path。而slow path是需要加MDL_lock::m_rwlock的写锁。m_fast_path_state = m_fast_path_state | MDL_lock::HAS_SLOW_PATH | MDL_lock::HAS_OBTRUSIVE
注:DDL还会获得库级别的意向排他MDL锁或者表级别的共享可升级锁，但为了表述方便，这里直接忽略了，只考虑涉及的同一个MDL_lock锁对象。
Session 4: SELECT * FROM sbtest1 WHERE id =3; // 检查m_fast_path_state &HAS_OBTRUSIVE，如果DDL还没跑完，就会走slow path。

从上面的描述可以看出，MDL子系统显式的对锁类型进行了区分（OBTRUSIVE or UNOBTRUSIVE），存储在数组矩阵m_unobtrusive_lock_increment。 因此对于相容类型的MDL锁类型，例如DML/SELECT，加锁操作几乎没有任何读写锁或MUTEX开销。对应WL#7304, WL#7306 ， PATCH（Rev:7067,Rev:7129）(Rev:7586)

第三，由于引入了MDL锁，实际上早期版本用于控制Server和引擎层表级并发的THR_LOCK 对于Innodb而言已经有些冗余了，因此Innodb表完全可以忽略这部分的开销。

不过在已有的逻辑中，Innodb依然依赖THR_LOCK来实现LOCK TABLE tbname READ，因此增加了新的MDL锁类型来代替这种实现。实际上代码的大部分修改都是为了处理新的MDL类型，Innodb的改动只有几行代码。对应WL#6671，PATCH(Rev:8232)

第四，Server层的用户锁（通过GET_LOCK函数获取）使用MDL来重新实现。

用户可以通过GET_LOCK()来同时获取多个用户锁，同时由于使用MDL来实现，可以借助MDL子系统实现死锁的检测。注意由于该变化，导致用户锁的命名必须小于64字节，这是受MDL子系统的限制导致。对应WL#1159, PATCH(Rev:8356)
MySQL·性能优化·hash_scan 算法的实现解析

问题描述

首先，我们执行下面的TestCase： 
 --source include/master-slave.inc
 --source include/have_binlog_format_row.inc
 connection slave;
 set global slave_rows_search_algorithms='TABLE_SCAN';
 connection master;
 create table t1(id int, name varchar(20);
 insert into t1 values(1,'a');
 insert into t2 values(2, 'b');
 ......
 insert into t3 values(1000, 'xxx');
 delete from t1;
 ---source include/rpl_end.inc

随着 t1 数据量的增大，rpl_hash_scan.test 的执行时间会随着 t1 数据量的增大而快速的增长，因为在执行 'delete from t1;' 对于t1的每一行删除操作，备库都要扫描t1,即全表扫描，如果 select count(*) from t1 = N, 则需要扫描Ｎ次 t1 表， 则读取记录数为： O(N + (N-1) + (N-2) + .... + 1) = O(N^2)，在 replication 没有引入 hash_scan，binlog_format=row时，对于无索引表，是通过 table_scan 实现的，如果一个update_rows_log_event/delete_rows_log_event 包含多行修改时，每个修改都要进行全表扫描来实现，其 stack 如下： 
#0 Rows_log_event::do_table_scan_and_update
#1 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#2 0x0000000000a28e3a in Log_event::apply_event
#3 0x0000000000a8365f in apply_event_and_update_pos
#4 0x0000000000a84764 in exec_relay_log_event 
#5 0x0000000000a89e97 in handle_slave_sql (arg=0x1b3e030) 
#6 0x0000000000e341c3 in pfs_spawn_thread (arg=0x2b7f48004b20) 
#7 0x0000003a00a07851 in start_thread () from /lib64/libpthread.so.0
#8 0x0000003a006e767d in clone () from /lib64/libc.so.6

这种情况下，往往会造成备库延迟，这也是无索引表所带来的复制延迟问题。
如何解决问题：

RDS 为了解这个问题，会在每个表创建的时候检查一下表是否包含主建或者唯一建，如果没有包含，则创建一个隐式主建，此主建对用户透明，用户无感，相应的show create, select * 等操作会屏蔽隐式主建，从而可以减少无索引表带来的影响;
官方为了解决这个问题，在5.6.6 及以后版本引入参数 slave_rows_search_algorithms ，用于指示备库在 apply_binlog_event时使用的算法，有三种算法TABLE_SCAN,INDEX_SCAN,HASH_SCAN，其中table_scan与index_scan是已经存在的，本文主要研究HASH_SCAN的实现方式，关于参数slave_rows_search_algorithms的设置。
hash_scan 的实现方法：

简单的讲，在apply rows_log_event时，会将 log_event 中对行的更新缓存在两个结构中，分别是：m_hash, m_distinct_key_list。 m_hash：主要用来缓存更新的行记录的起始位置，是一个hash表； m_distinct_key_list：如果有索引，则将索引的值push 到m_distinct_key_list，如果表没有索引，则不使用这个List结构； 其中预扫描整个调用过程如下： Log_event::apply_event 
 Rows_log_event::do_apply_event
    Rows_log_event::do_hash_scan_and_update 
      Rows_log_event::do_hash_row  (add entry info of changed records)
        if (m_key_index < MAX_KEY) (index used instead of table scan)
          Rows_log_event::add_key_to_distinct_keyset ()

当一个event 中包含多个行的更改时，会首先扫描所有的更改，将结果缓存到m_hash中，如果该表有索引，则将索引的值缓存至m_distinct_key_list List 中，如果没有，则不使用这个缓存结构，而直接进行全表扫描；
执行 stack 如下： 
#0 handler::ha_delete_row 
#1 0x0000000000a4192b in Delete_rows_log_event::do_exec_row 
#2 0x0000000000a3a9c8 in Rows_log_event::do_apply_row
#3 0x0000000000a3c1f4 in Rows_log_event::do_scan_and_update 
#4 0x0000000000a3c5ef in Rows_log_event::do_hash_scan_and_update 
#5 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#6 0x0000000000a28e3a in Log_event::apply_event
#7 0x0000000000a8365f in apply_event_and_update_pos
#8 0x0000000000a84764 in exec_relay_log_event 
#9 0x0000000000a89e97 in handle_slave_sql
#10 0x0000000000e341c3 in pfs_spawn_thread
#11 0x0000003a00a07851 in start_thread () 
#12 0x0000003a006e767d in clone ()

执行过程说明：

Rows_log_event::do_scan_and_update 
  open_record_scan()
    do
      next_record_scan()
        if (m_key_index > MAX_KEY)
           ha_rnd_next();
        else
           ha_index_read_map(m_key from m_distinct_key_list)       
        entry= m_hash->get()
        m_hash->del(entry);
        do_apply_row()
     while (m_hash->size > 0);

从执行过程上可以看出，当使用hash_scan时，只会全表扫描一次，虽然会多次遍历m_hash这个hash表，但是这个扫描是O(1),所以，代价很小，因此可以降低扫描次数，提高执行效率。
hash_scan 的一个 bug

引用
bug详情：http://bugs.mysql.com/bug.php?id=72788
bug原因：m_distinct_key_list 中的index key 不是唯一的，所以存在着对已经删除了的记录重复删除的问题。
bug修复：http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8494


问题扩展：

  • 在没有索引的情况下，是不是把 hash_scan 打开就能提高效率，降低延迟呢？不一定，如果每次更新操作只一条记录，此时仍然需要全表扫描，并且由于entry 的开销，应该会有后退的情况；
  • 一个event中能包含多少条记录的更新呢？这个和表结构以及记录的数据大小有关，一个event 的大小不会超过9000 bytes, 没有参数可以控制这个size；
  • hash_scan 有没有限制呢？hash_scan 只会对更新、删除操作有效，对于binlog_format=statement 产生的 Query_log_event 或者binlog_format=row 时产生的 Write_rows_log_event 不起作用；

TokuDB·版本优化·7.5.0

TokuDB　7.5.0大版本已发布，是一个里程碑的版本，这里谈几点优化，以飨存储引擎爱好者们。

a) shutdown加速

有用户反馈TokuDB在shutdown的时候，半个小时还没完事，非常不可接受。在shutdown的时候，TokuDB在干什么呢？在做checkpoint，把内存中的节点数据序列化并压缩到磁盘。

那为什么如此耗时呢？如果tokudb_cache_size开的比较大，内存中的节点会非常多，在shutdown的时候，大家都排队等着被压缩到磁盘（串行的）。

在7.5.0版本，TokuDB官方针对此问题进行了优化，使多个节点并行压缩来缩短时间。

BTW: TokuDB在早期设计的时候已保留并行接口，只是一直未开启。

b) 内节点读取加速

在内存中，TokuDB内节点(internal node)的每个message buffer都有２个重要数据结构：

1) FIFO结构，保存{key, value}
2) OMT结构，保存{key, FIFO-offset}
由于FIFO不具备快速查找特性，就利用OMT来做快速查找(根据key查到value)。这样，当内节点发生cache miss的时候，索引层需要做：

1) 从磁盘读取节点内容到内存
2) 构造FIFO结构
3) 根据FIFO构造OMT结构(做排序)
由于TokuDB内部有不少性能探(ji)针(shu)，他们发现步骤3)是个不小的性能消耗点，因为每次都要把message buffer做下排序构造出OMT，于是在7.5.0版本，把OMT的FIFO-offset(已排序)也持久化到磁盘，这样排序的损耗就没了。

c) 顺序写加速

当写发生的时候，会根据当前的key在pivots里查找(二分)当前写要落入哪个mesage buffer，如果写是顺序(或局部顺序，数据走向为最右边路径)的，就可以避免由＂查找＂带来的额外开销。



如何判断是顺序写呢？TokuDB使用了一种简单的启发式方法(heurstic)：seqinsert_score积分式。如果：
引用
1) 当前写入落入最右节点，对seqinsert_score加一分(原子)
2) 当前写入落入非最右节点，对seqinsert_score清零(原子)

当seqinsert_score大于100的时候，就可以认为是顺序写，当下次写操作发生时，首先与最右的节点pivot进行对比判断，如果确实为顺序写，则会被写到该节点，省去不少compare开销。方法简单而有效。
MariaDB·　性能优化·filesort with small LIMIT optimization

从MySQL 5.6.2/MariaDB 10.0.0版本开始，MySQL/MariaDB针对"ORDER BY ...LIMIT n"语句实现了一种新的优化策略。当n足够小的时候，优化器会采用一个容积为n的优先队列来进行排序，而不是排序所有数据然后取出前n条。 这个新算法可以这么描述：（假设是ASC排序）

1.建立一个只有n个元素的优先队列（堆），根节点为堆中最大元素
2.根据其他条件，依次从表中取出一行数据
3.如果当前行的排序关键字小于堆头，则把当前元素替换堆头，重新Shift保持堆的特性
4.再取一条数据重复2步骤，如果没有下一条数据则执行5
5.依次取出堆中的元素（从大到小排序），逆序输出（从小到大排序），即可得ASC的排序结果
这样的算法，时间复杂度为m*log(n)，m为索引过滤后的行数，n为LIMIT的行数。而原始的全排序算法，时间复杂度为m*log(m)。只要n远小于m，这个算法就会很有效。

不过在MySQL 5.6中，除了optimizer_trace，没有好的方法来看到这个新的执行计划到底起了多少作用。MariaDB 10.013开始，提供一个系统状态，可以查看新执行计划调用的次数：
引用
Sort_priority_queue_sorts
描述: 通过优先队列实现排序的次数。(总排序次数=Sort_range+Sort_scan)
范围: Global, Session
数据类型: numeric
引入版本: MariaDB 10.0.13

此外，MariaDB还将此信息打入了Slow Log中。只要指定 log_slow_verbosity=query_plan，就可以在Slow Log中看到这样的记录： 
# Time: 140714 18:30:39
 # User@Host: root[root] @ localhost []
 # Thread_id: 3  Schema: test  QC_hit: No
 # Query_time: 0.053857  Lock_time: 0.000188  Rows_sent: 11  Rows_examined: 100011
 # Full_scan: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
 # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0  Priority_queue: Yes
 SET timestamp=1405348239;SET timestamp=1405348239;
 select * from t1 where col1 between 10 and 20 order by col2 limit 100;

"Priority_queue: Yes" 就表示这个Query利用了优先队列的执行计划(pt-query-digest 目前已经可以解析 Priority_queue 这个列)。更多精彩内容，敬请期待！
本文转载自MySQL.taobao.org ，感谢淘宝数据库项目组丁奇、鸣嵩、彭立勋、皓庭、项仲、剑川、武藏、祁奚、褚霸、一工。
  • 大小: 42.4 KB
6
顶
0
踩
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 淘宝内部分享：MySQL & MariaDB性能优化 【转】

    MySQL·　5.7优化·Metadata Lock子系统的优化 背景 引入MDL锁的目的，最初是为了解决著名的bug#989，在MySQL 5.1及之前的版本，事务执行过程中并不维护涉及到的所有表的Metatdata 锁，极易出现复制中断，例如...

  • 淘宝内部分享：怎么跳出MySQL的10个大坑

    Mysql 对于大数据处理确实是一个坑需要花很多时间去研究提升性能。淘宝自从2010开始规模使用MySQL，替换了之前商品、交易、用户等原基于IOE方案的核心数据库，目前已部署数千台规模。同时和Oracle, Percona, Mariadb...

  • [转]淘宝内部分享：怎么跳出MySQL的10个大坑

    淘宝自从2010开始规模使用MySQL，替换了之前商品、交易、用户等原基于IOE方案的核心数据库，目前已部署数千台规模。本文涉及以下几个方向：单机，提升单机数据库的性能；集群，提供扩展可靠性；IO存储体系等。

  • 毕业设计选题 -未来生鲜运输车设计.pptx

    毕业设计选题 -未来生鲜运输车设计.pptx

  • 基于樽海鞘算法优化的极限学习机回归预测及其与BP、GRNN、ELM的性能对比研究

    内容概要：本文详细探讨了基于樽海鞘算法（SSA）优化的极限学习机（ELM）在回归预测任务中的应用，并与传统的BP神经网络、广义回归神经网络（GRNN）以及未优化的ELM进行了性能对比。首先介绍了ELM的基本原理，即通过随机生成输入层与隐藏层之间的连接权重及阈值，仅需计算输出权重即可快速完成训练。接着阐述了SSA的工作机制，利用樽海鞘群体觅食行为优化ELM的输入权重和隐藏层阈值，从而提高模型性能。随后分别给出了BP、GRNN、ELM和SSA-ELM的具体实现代码，并通过波士顿房价数据集和其他工业数据集验证了各模型的表现。结果显示，SSA-ELM在预测精度方面显著优于其他三种方法，尽管其训练时间较长，但在实际应用中仍具有明显优势。 适合人群：对机器学习尤其是回归预测感兴趣的科研人员和技术开发者，特别是那些希望深入了解ELM及其优化方法的人。 使用场景及目标：适用于需要高效、高精度回归预测的应用场景，如金融建模、工业数据分析等。主要目标是提供一种更为有效的回归预测解决方案，尤其是在处理大规模数据集时能够保持较高的预测精度。 其他说明：文中提供了详细的代码示例和性能对比图表，帮助读者更好地理解和复现实验结果。同时提醒使用者注意SSA参数的选择对模型性能的影响，建议进行参数敏感性分析以获得最佳效果。

  • 2025年中国生成式AI大会PPT（4-1）

    2025年中国生成式AI大会PPT（4-1）

  • 无刷直流电机双闭环调速系统的Simulink建模与参数优化

    内容概要：本文详细介绍了基于Simulink平台构建无刷直流电机（BLDC）双闭环调速系统的全过程。首先阐述了双闭环控制系统的基本架构，即外层速度环和内层电流环的工作原理及其相互关系。接着深入探讨了PWM生成模块的设计，特别是占空比计算方法的选择以及三角波频率的设定。文中还提供了详细的电机参数设置指导，如转动惯量、电感、电阻等，并强调了参数选择对系统性能的影响。此外，针对PI控制器的参数整定给出了具体的公式和经验值，同时分享了一些实用的调试技巧，如避免转速超调、处理启动抖动等问题的方法。最后，通过仿真实验展示了系统的稳定性和鲁棒性，验证了所提出方法的有效性。 适用人群：从事电机控制研究的技术人员、自动化工程领域的研究生及科研工作者。 使用场景及目标：适用于需要深入了解和掌握无刷直流电机双闭环调速系统设计与优化的人群。主要目标是帮助读者学会利用Simulink进行BLDC电机控制系统的建模、仿真和参数优化，从而提高系统的稳定性和响应速度。 其他说明：文章不仅提供了理论知识，还包括了许多实践经验和技术细节，有助于读者更好地理解和应用相关技术。

  • 西门子S7-1200 PLC与施耐德变频器Modbus通讯实现及调试技巧

    内容概要：本文详细介绍了西门子S7-1200 PLC与施耐德ATV310/312变频器通过Modbus RTU进行通讯的具体实现步骤和调试技巧。主要内容涵盖硬件接线、通讯参数配置、控制启停、设定频率、读取运行参数的方法以及常见的调试问题及其解决方案。文中提供了具体的代码示例，帮助读者理解和实施通讯程序。此外，还强调了注意事项，如地址偏移量、数据格式转换和超时匹配等。 适合人群：从事工业自动化领域的工程师和技术人员，尤其是那些需要将西门子PLC与施耐德变频器进行集成的工作人员。 使用场景及目标：适用于需要通过Modbus RTU协议实现PLC与变频器通讯的工程项目。目标是确保通讯稳定可靠，掌握解决常见问题的方法，提高调试效率。 其他说明：文中提到的实际案例和调试经验有助于读者避免常见错误，快速定位并解决问题。建议读者在实践中结合提供的代码示例和调试工具进行操作。

  • 基于FPGA的Verilog实现IIC主从机驱动及其应用

    内容概要：本文详细介绍了如何使用Verilog在FPGA上实现IIC（Inter-Integrated Circuit）主从机驱动。主要内容包括从机和主机的设计，特别是状态机的实现、寄存器读取、时钟分频策略、SDA线的三态控制等关键技术。文中还提供了详细的代码片段，展示了从机地址匹配逻辑、主机时钟生成逻辑、顶层模块的连接方法以及仿真实验的具体步骤。此外，文章讨论了一些常见的调试问题，如总线竞争、时序不匹配等，并给出了相应的解决方案。 适合人群：具备一定FPGA开发基础的技术人员，尤其是对IIC协议感兴趣的嵌入式系统开发者。 使用场景及目标：适用于需要在FPGA平台上实现高效、可靠的IIC通信的应用场景。主要目标是帮助读者掌握IIC协议的工作原理，能够独立完成IIC主从机系统的开发和调试。 其他说明：文章不仅提供了理论讲解，还包括了大量的实战经验和代码实例，有助于读者更好地理解和应用所学知识。同时，文章还提供了一个思考题，引导读者进一步探索多主设备仲裁机制的设计思路。

  • C#开发的拖拽式Halcon可视化抓边抓圆控件，提升机器视觉测量效率

    内容概要：本文介绍了一款基于C#开发的拖拽式Halcon可视化抓边、抓圆控件，旨在简化机器视觉项目中的测量任务。该控件通过拖拽操作即可快速生成测量区域，自动完成边缘坐标提取，并提供实时反馈。文中详细描述了控件的工作原理和技术细节，如坐标系转换、卡尺生成、边缘检测算法封装以及动态参数调试等功能。此外，还讨论了一些常见问题及其解决方案，如坐标系差异、内存管理等。 适合人群：从事机器视觉开发的技术人员，尤其是熟悉C#和Halcon的开发者。 使用场景及目标：适用于需要频繁进行边缘和圆形特征测量的工业自动化项目，能够显著提高测量效率并减少编码工作量。主要目标是将复杂的测量任务转化为简单的拖拽操作，使非专业人员也能轻松完成测量配置。 其他说明：该控件已开源发布在GitHub上，提供了完整的源代码和详细的使用指南。未来计划扩展更多高级功能，如自动路径规划和亚像素级齿轮齿距检测等。

  • 西门子200Smart与维纶触摸屏在疫苗车间控制系统的应用：配液、发酵、纯化及CIP清洗工艺详解

    内容概要：本文详细介绍了西门子200Smart PLC与维纶触摸屏在某疫苗车间控制系统的具体应用，涵盖配液、发酵、纯化及CIP清洗四个主要工艺环节。文中不仅展示了具体的编程代码和技术细节，还分享了许多实战经验和调试技巧。例如，在配液罐中，通过模拟量处理确保温度和液位的精确控制；发酵罐部分，着重讨论了PID参数整定和USS通讯控制变频器的方法；纯化过程中，强调了双PID串级控制的应用；CIP清洗环节，则涉及复杂的定时器逻辑和阀门联锁机制。此外，文章还提到了一些常见的陷阱及其解决方案，如通讯干扰、状态机切换等问题。 适合人群：具有一定PLC编程基础的技术人员，尤其是从事工业自动化领域的工程师。 使用场景及目标：适用于需要深入了解PLC与触摸屏集成控制系统的工程师，帮助他们在实际项目中更好地理解和应用相关技术和方法，提高系统的稳定性和可靠性。 其他说明：文章提供了大量实战经验和代码片段，有助于读者快速掌握关键技术点，并避免常见错误。同时，文中提到的一些优化措施和调试技巧对提升系统性能非常有帮助。

  • 计算机网络结课设计：通过思科Cisco进行中小型校园网搭建

    计算机网络课程的结课设计是使用思科模拟器搭建一个中小型校园网，当时花了几天时间查阅相关博客总算是做出来了，现在免费上传CSDN，希望小伙伴们能给博客一套三连支持

  • 芋道（yudao）开发技术文档

    《芋道开发指南文档-2023-10-27更新》是针对软件开发者和IT专业人士的一份详尽的资源集合，旨在提供最新的开发实践、范例代码和最佳策略。这份2023年10月27日更新的文档集，包含了丰富的模板和素材，帮助开发者在日常工作中提高效率，保证项目的顺利进行。 让我们深入探讨这份文档的可能内容。"芋道"可能是一个开源项目或一个专业的技术社区，其开发指南涵盖了多个方面，例如： 1. **编程语言指南**：可能包括Java、Python、JavaScript、C++等主流语言的编码规范、最佳实践以及常见问题的解决方案。 2. **框架与库的应用**：可能会讲解React、Vue、Angular等前端框架，以及Django、Spring Boot等后端框架的使用技巧和常见应用场景。 3. **数据库管理**：涵盖了SQL语言的基本操作，数据库设计原则，以及如何高效使用MySQL、PostgreSQL、MongoDB等数据库系统。 4. **版本控制**：详细介绍了Git的工作流程，分支管理策略，以及与其他开发工具（如Visual Studio Code、IntelliJ IDEA）的集成。 5. **持续集成与持续部署(CI/CD)**：包括Jenkins、Travis CI、GitHub Actions等工具的配置和使用，以实现自动化测试和部署。 6. **云服务与容器化**：可能涉及AWS、Azure、Google Cloud Platform等云计算平台的使用，以及Docker和Kubernetes的容器化部署实践。 7. **API设计与测试**：讲解RESTful API的设计原则，Swagger的使用，以及Postman等工具进行API测试的方法。 8. **安全性与隐私保护**：涵盖OAuth、JWT认证机制，HTTPS安全通信，以及防止SQL注入、

  • 基于信息间隙决策的综合能源系统优化调度模型及其应用

    内容概要：本文介绍了一种先进的综合能源系统优化调度模型，该模型将风电、光伏、光热发电等新能源与燃气轮机、燃气锅炉等传统能源设备相结合，利用信息间隙决策（IGDT）处理不确定性。模型中引入了P2G（电转气）装置和碳捕集技术，实现了碳经济闭环。通过多能转换和储能系统的协同调度，提高了系统的灵活性和鲁棒性。文中详细介绍了模型的关键组件和技术实现，包括IGDT的鲁棒性参数设置、P2G与碳捕集的协同控制、储能系统的三维协同调度等。此外，模型展示了在极端天气和负荷波动下的优异表现，显著降低了碳排放成本并提高了能源利用效率。 适合人群：从事能源系统优化、电力调度、碳交易等相关领域的研究人员和工程师。 使用场景及目标：适用于需要处理多种能源形式和不确定性的综合能源系统调度场景。主要目标是提高系统的灵活性、鲁棒性和经济效益，减少碳排放。 其他说明：模型具有良好的扩展性，可以通过修改配置文件轻松集成新的能源设备。代码中包含了详细的注释和公式推导，便于理解和进一步改进。

  • 毕业设计的论文撰写、终期答辩相关的资源.m

    毕业设计的论文撰写、终期答辩相关的资源

  • 机器学习（预测模型）：专注于 2024 年出现的漏洞（CVE）信息数据集

    该是一个在 Kaggle 上发布的数据集，专注于 2024 年出现的漏洞（CVE）信息。以下是关于该数据集的详细介绍：该数据集收集了 2024 年记录在案的各类漏洞信息，涵盖了漏洞的利用方式（Exploits）、通用漏洞评分系统（CVSS）评分以及受影响的操作系统（OS）。通过整合这些信息，研究人员和安全专家可以全面了解每个漏洞的潜在威胁、影响范围以及可能的攻击途径。数据主要来源于权威的漏洞信息平台，如美国国家漏洞数据库（NVD）等。这些数据经过整理和筛选后被纳入数据集，确保了信息的准确性和可靠性。数据集特点：全面性：涵盖了多种操作系统（如 Windows、Linux、Android 等）的漏洞信息，反映了不同平台的安全状况。实用性：CVSS 评分提供了漏洞严重程度的量化指标，帮助用户快速评估漏洞的优先级。同时，漏洞利用信息（Exploits）为安全研究人员提供了攻击者可能的攻击手段，有助于提前制定防御策略。时效性：专注于 2024 年的漏洞数据，反映了当前网络安全领域面临的新挑战和新趋势。该数据集可用于多种研究和实践场景： 安全研究：研究人员可以利用该数据集分析漏洞的分布规律、攻击趋势以及不同操作系统之间的安全差异，为网络安全防护提供理论支持。 机器学习与数据分析：数据集中的结构化信息适合用于机器学习模型的训练，例如预测漏洞的 CVSS 评分、识别潜在的高危漏洞等。 企业安全评估：企业安全团队可以参考该数据集中的漏洞信息，结合自身系统的实际情况，进行安全评估和漏洞修复计划的制定。

  • 建模大赛入门指南：从零基础到实战应用.pdf

    内容概要：本文档作为建模大赛的入门指南，详细介绍了建模大赛的概念、类型、竞赛流程、核心步骤与技巧，并提供实战案例解析。文档首先概述了建模大赛，指出其以数学、计算机技术为核心，主要分为数学建模、3D建模和AI大模型竞赛三类。接着深入解析了数学建模竞赛，涵盖组队策略（如三人分别负责建模、编程、论文写作）、时间安排（72小时内完成全流程）以及问题分析、模型建立、编程实现和论文撰写的要点。文中还提供了物流路径优化的实战案例，展示了如何将实际问题转化为图论问题并采用Dijkstra或蚁群算法求解。最后，文档推荐了不同类型建模的学习资源与工具，并给出了新手避坑建议，如避免过度复杂化模型、重视可视化呈现等。; 适合人群：对建模大赛感兴趣的初学者，特别是高校学生及希望参与数学建模竞赛的新手。; 使用场景及目标：①了解建模大赛的基本概念和分类；②掌握数学建模竞赛的具体流程与分工；③学习如何将实际问题转化为数学模型并求解；④获取实战经验和常见错误规避方法。; 其他说明：文档不仅提供了理论知识，还结合具体实例和代码片段帮助读者更好地理解和实践建模过程。建议新手从中小型赛事开始积累经验，逐步提升技能水平。

Global site tag (gtag.js) - Google Analytics