GreatSQL删除分区慢的跟踪

Hive执行set命令的时候报cannot modify xxx at runtime 阅读详情

GreatSQL删除分区慢的跟踪

背景

某业务系统,每天凌晨会删除分区表的一个分区(按天分区),耗时较久,从最开始的30秒,慢慢变为1分钟+,影响到交易业务的正常进行。 在测试环境进行了模拟,复现了删除分区慢的情况,本次基于GreatSQL8.0.25-17进行测试,官方mysql版本也存在相同问题。

测试环境

$ mysql -h127.0.0.1 -P8025 -uroot -p

mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.25-17 GreatSQL, Release 17, Revision 4733775f703

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

greatsql> select version();
+-----------+
| version() |
+-----------+
| 8.0.25-17 |
+-----------+
1 row in set (0.00 sec)
greatsql> show variables like 'autocommit' ;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.01 sec)

greatsql> show variables like 'innodb_buffer_pool_size';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 4294967296 |
+-------------------------+------------+
1 row in set (0.01 sec)

greatsql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

greatsql> show variables like 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1     |
+---------------+-------+
1 row in set (0.00 sec)

建表

CREATE TABLE `t_partition` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `ua` varchar(100) DEFAULT NULL,
  `start_time` datetime NOT NULL,
  PRIMARY KEY (`id`,`start_time`)
)  PARTITION BY RANGE (to_days(`start_time`))
(PARTITION P20230129 VALUES LESS THAN (738915) ENGINE = InnoDB,
 PARTITION P20230130 VALUES LESS THAN (738916) ENGINE = InnoDB,
 PARTITION P20230131 VALUES LESS THAN (738917) ENGINE = InnoDB,
 PARTITION P20230201 VALUES LESS THAN (738918) ENGINE = InnoDB,
 PARTITION P20230202 VALUES LESS THAN (738919) ENGINE = InnoDB,
 PARTITION P20230203 VALUES LESS THAN (738920) ENGINE = InnoDB,
 PARTITION P20230204 VALUES LESS THAN (738921) ENGINE = InnoDB,
 PARTITION P20230302 VALUES LESS THAN (738947) ENGINE = InnoDB,
 PARTITION P20230303 VALUES LESS THAN (738948) ENGINE = InnoDB,
 PARTITION P20230304 VALUES LESS THAN (738949) ENGINE = InnoDB,
 PARTITION P20230305 VALUES LESS THAN (738950) ENGINE = InnoDB,
 PARTITION P20230306 VALUES LESS THAN (738951) ENGINE = InnoDB,
 PARTITION P20230307 VALUES LESS THAN (738952) ENGINE = InnoDB, 
 PARTITION P20230308 VALUES LESS THAN (738953) ENGINE = InnoDB,
 PARTITION P20230309 VALUES LESS THAN (738954) ENGINE = InnoDB,
 PARTITION P20230310 VALUES LESS THAN (738955) ENGINE = InnoDB, 
 PARTITION P20230311 VALUES LESS THAN (738956) ENGINE = InnoDB, 

 PARTITION P20230312 VALUES LESS THAN (738957) ENGINE = InnoDB,
 PARTITION P20230313 VALUES LESS THAN (738958) ENGINE = InnoDB,
 PARTITION P20230314 VALUES LESS THAN (738959) ENGINE = InnoDB,
 PARTITION P20230315 VALUES LESS THAN (738960) ENGINE = InnoDB,
 PARTITION P20230316 VALUES LESS THAN (738961) ENGINE = InnoDB,
 PARTITION P20230317 VALUES LESS THAN (738962) ENGINE = InnoDB, 
 PARTITION P20230318 VALUES LESS THAN (738963) ENGINE = InnoDB,
 PARTITION P20230319 VALUES LESS THAN (738964) ENGINE = InnoDB,
 PARTITION P20230320 VALUES LESS THAN (738965) ENGINE = InnoDB, 
 PARTITION P20230321 VALUES LESS THAN (738966) ENGINE = InnoDB, 

 PARTITION P20230322 VALUES LESS THAN (738967) ENGINE = InnoDB,
 PARTITION P20230323 VALUES LESS THAN (738968) ENGINE = InnoDB,
 PARTITION P20230324 VALUES LESS THAN (738969) ENGINE = InnoDB,
 PARTITION P20230325 VALUES LESS THAN (738970) ENGINE = InnoDB,
 PARTITION P20230326 VALUES LESS THAN (738971) ENGINE = InnoDB,
 PARTITION P20230327 VALUES LESS THAN (738972) ENGINE = InnoDB, 
 PARTITION P20230328 VALUES LESS THAN (738973) ENGINE = InnoDB,
 PARTITION p20230329 VALUES LESS THAN (738974) ENGINE = InnoDB,
 PARTITION p20230330 VALUES LESS THAN (738975) ENGINE = InnoDB,
 PARTITION p20230331 VALUES LESS THAN (738976) ENGINE = InnoDB,
 PARTITION p20230401 VALUES LESS THAN (738977) ENGINE = InnoDB,
 PARTITION p20230402 VALUES LESS THAN (738978) ENGINE = InnoDB,
 PARTITION p20230403 VALUES LESS THAN (738979) ENGINE = InnoDB);

插入数据

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-10' ;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-10' ;
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-10' ;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0



greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),start_time from t_partition; 
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),start_time from t_partition; 
Query OK, 6 rows affected (0.00 sec)
Records: 6  Duplicates: 0  Warnings: 0

............... 
greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),start_time from t_partition; 
Query OK, 3145728 rows affected (35.68 sec)
Records: 3145728  Duplicates: 0  Warnings: 0

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),start_time from t_partition; 
Query OK, 6291456 rows affected (1 min 11.51 sec)
Records: 6291456  Duplicates: 0  Warnings: 0

greatsql> insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),start_time from t_partition; 
Query OK, 12582912 rows affected (2 min 26.74 sec)
Records: 12582912  Duplicates: 0  Warnings: 0

greatsql> select count(*) from t_partition; 
+----------+
| count(*) |
+----------+
| 25165824 |
+----------+
1 row in set (0.50 sec)
greatsql> select count(*) from t_partition partition(P20230310); 
+----------+
| count(*) |
+----------+
| 25165824 |
+----------+ 

向分区插入数据

insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-11' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-12' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-13' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-14' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-15' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-16' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-17' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-18' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-19' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-20' from t_partition partition(P20230310); 
 insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-21' from t_partition partition(P20230310); 

 。。。。。。。。。。。
greatsql>  insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-19' from t_partition partition(P20230310); 
Query OK, 25165824 rows affected (5 min 17.92 sec)
Records: 25165824  Duplicates: 0  Warnings: 0

greatsql>  insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-20' from t_partition partition(P20230310); 
Query OK, 25165824 rows affected (5 min 19.56 sec)
Records: 25165824  Duplicates: 0  Warnings: 0

greatsql>  insert into t_partition(ua,start_time) select substring(md5(rand()),1,20),'2023-03-21' from t_partition partition(P20230310); 
Query OK, 25165824 rows affected (5 min 27.27 sec)
Records: 25165824  Duplicates: 0  Warnings: 0

更新数据

greatsql> Update t_partition set ua=concat(ua,'abc') where start_time='2023-03-19';
Query OK, 25165824 rows affected (12 min 55.53 sec)
Rows matched: 25165824  Changed: 25165824  Warnings: 0

删除分区s

greatsql> alter table t_partition drop partition P20230311;

Query OK, 0 rows affected (13.68 sec)

Records: 0 Duplicates: 0 Warnings: 0

greatsql> alter table t_partition drop partition P20230312;

Query OK, 0 rows affected (0.07 sec)

Records: 0 Duplicates: 0 Warnings: 0

两个分区数据量是一样,但删除第一个分区耗时较长。

$ perf record -ag -p  11222  -o /mysqldb/perf_drop_part_mysql2.data

Warning:
PID/TID switch overriding SYSTEM
^C[ perf record: Woken up 41 times to write data ]
[ perf record: Captured and wrote 10.610 MB /mysqldb/perf_drop_part_mysql2.data (54351 samples) ]
  Children      Self  Command  Shared Object        Symbol                                                   
+   99.17%     0.00%  mysqld   libpthread-2.17.so   [.] start_thread                                         
+   99.17%     0.00%  mysqld   mysqld               [.] pfs_spawn_thread                                     
+   99.17%     0.00%  mysqld   mysqld               [.] handle_connection                                    
+   99.17%     0.00%  mysqld   mysqld               [.] do_command                                           
+   99.17%     0.00%  mysqld   mysqld               [.] dispatch_command                                     
+   99.17%     0.00%  mysqld   mysqld               [.] dispatch_sql_command                                 
+   99.16%     0.00%  mysqld   mysqld               [.] mysql_execute_command                                
+   99.16%     0.00%  mysqld   mysqld               [.] Sql_cmd_alter_table::execute                         
+   99.16%     0.00%  mysqld   mysqld               [.] mysql_alter_table                                    
+   99.09%     0.00%  mysqld   mysqld               [.] mysql_inplace_alter_table                            
+   98.56%     0.00%  mysqld   mysqld               [.] ha_innopart::commit_inplace_alter_partition          
+   98.54%     0.00%  mysqld   mysqld               [.] alter_parts::prepare_or_commit_for_new               
+   98.54%     0.00%  mysqld   mysqld               [.] alter_part_normal::try_commit                        
+   98.53%     0.00%  mysqld   mysqld               [.] btr_drop_ahi_for_table                               
+   98.52%     1.30%  mysqld   mysqld               [.] btr_drop_next_batch                                  
+   97.20%     0.03%  mysqld   mysqld               [.] btr_search_drop_page_hash_when_freed                 
+   96.34%     2.03%  mysqld   mysqld               [.] btr_search_drop_page_hash_index                      
+   86.52%    52.25%  mysqld   mysqld               [.] ha_remove_all_nodes_to_page                          
+   34.21%    34.15%  mysqld   mysqld               [.] ha_delete_hash_node                                  
+    4.27%     2.68%  mysqld   mysqld               [.] rec_get_offsets_func                                 
+    2.11%     2.10%  mysqld   mysqld               [.] ut_fold_binary                                       
+    1.58%     1.58%  mysqld   mysqld               [.] rec_init_offsets                                     
+    1.30%     1.30%  mysqld   mysqld               [.] rec_fold                                             
+    0.57%     0.03%  mysqld   mysqld               [.] buf_page_get_gen                                     
+    0.57%     0.00%  mysqld   mysqld               [.] execute_native_thread_routine                        
+    0.56%     0.01%  mysqld   [kernel.kallsyms]    [k] system_call_fastpath

从系统调用上看有大量的自适应hash相关的调用

重启关闭自适应hash

greatsql> show variables like '%hash%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| innodb_adaptive_hash_index       | OFF   |
| innodb_adaptive_hash_index_parts | 8     |
+----------------------------------+-------+

修改配置文件,关闭自适应hash,按照上面的流程从新执行

greatsql> alter table t_partition drop partition P20230311;

Query OK, 0 rows affected (0.08 sec)

Records: 0 Duplicates: 0 Warnings: 0

greatsql> alter table t_partition drop partition P20230312;

Query OK, 0 rows affected (0.08 sec)

Records: 0 Duplicates: 0 Warnings: 0

关闭自适应hash后,相同的操作过程,删除第一个分区的时间明显变短,删除每个分区的时间基本上一致。

备注:innodb_adaptive_hash_index是全局变量,可以动态修改,不重启数据库。

测试结果汇总

自适应hash对比第一次删分区第二次删分区
innodb_buffer_pool_instances=8& innodb_adaptive_hash_index=on13.680.07
innodb_buffer_pool_instances=8& innodb_adaptive_hash_index=off0.080.08

源码分析

// btr_drop_ahi_for_table
void btr_drop_ahi_for_table(dict_table_t *table) {
  const ulint len = UT_LIST_GET_LEN(table->indexes);

  if (len == 0) {
    return;
  }

  const dict_index_t *indexes[MAX_INDEXES];
  const page_size_t page_size(dict_table_page_size(table));

  for (;;) {
    ulint ref_count = 0;
    const dict_index_t **end = indexes;

    for (dict_index_t *index = table->first_index(); index != nullptr;
         index = index->next()) {
      if (ulint n_refs = index->search_info->ref_count) {
        ut_ad(!index->disable_ahi);
        ut_ad(index->is_committed());
        ref_count += n_refs;
        ut_ad(indexes + len > end);
        *end++ = index;
      }
    }

    ut_ad((indexes == end) == (ref_count == 0));

    if (ref_count == 0) {
      return;
    }

    btr_drop_next_batch(page_size, indexes, end);  // breakpoint  

    std::this_thread::yield();
  }
}



// btr_drop_next_batch
static void btr_drop_next_batch(const page_size_t &page_size,
                                const dict_index_t **first,
                                const dict_index_t **last) {
  static constexpr unsigned batch_size = 1024;
  std::vector<page_id_t> to_drop;
  to_drop.reserve(batch_size);

  for (ulint i = 0; i < srv_buf_pool_instances; ++i) {
    to_drop.clear();
    buf_pool_t *buf_pool = buf_pool_from_array(i);
    mutex_enter(&buf_pool->LRU_list_mutex);
    const buf_page_t *prev;

    for (const buf_page_t *bpage = UT_LIST_GET_LAST(buf_pool->LRU);
         bpage != nullptr; bpage = prev) {
      prev = UT_LIST_GET_PREV(LRU, bpage);

      ut_a(buf_page_in_file(bpage));
      if (buf_page_get_state(bpage) != BUF_BLOCK_FILE_PAGE ||
          bpage->buf_fix_count > 0) {
        continue;
      }

      const dict_index_t *block_index =
          reinterpret_cast<const buf_block_t *>(bpage)->ahi.index;

      /* index == nullptr means the page is no longer in AHI, so no need to
      attempt freeing it */
      if (block_index == nullptr) {
        continue;
      }
      /* pages IO fixed for read have index == nullptr */
      ut_ad(!bpage->was_io_fix_read());

      if (std::find(first, last, block_index) != last) {
        to_drop.emplace_back(bpage->id);
        if (to_drop.size() == batch_size) {   // batch_size = 1024
          break;
        }
      }
    }

    mutex_exit(&buf_pool->LRU_list_mutex);

    for (const page_id_t &page_id : to_drop) {
      btr_search_drop_page_hash_when_freed(page_id, page_size); // breakpoint
    }
  }
}

// btr_search_drop_page_hash_when_freed
void btr_search_drop_page_hash_when_freed(const page_id_t &page_id,
                                          const page_size_t &page_size) {
  buf_block_t *block;
  mtr_t mtr;

  ut_d(export_vars.innodb_ahi_drop_lookups++);

  mtr_start(&mtr);

  /* If the caller has a latch on the page, then the caller must
  have a x-latch on the page and it must have already dropped
  the hash index for the page. Because of the x-latch that we
  are possibly holding, we cannot s-latch the page, but must
  (recursively) x-latch it, even though we are only reading. */

  block = buf_page_get_gen(page_id, page_size, RW_X_LATCH, nullptr,
                           Page_fetch::PEEK_IF_IN_POOL, UT_LOCATION_HERE, &mtr);

  if (block) {
    /* If AHI is still valid, page can't be in free state.
    AHI is dropped when page is freed. */
    ut_ad(!block->page.file_page_was_freed);

    buf_block_dbg_add_level(block, SYNC_TREE_NODE_FROM_HASH);

    dict_index_t *index = block->ahi.index;
    if (index != nullptr) {
      /* In all our callers, the table handle should
      be open, or we should be in the process of
      dropping the table (preventing eviction). */
      ut_ad(index->table->n_ref_count > 0 || dict_sys_mutex_own());
      btr_search_drop_page_hash_index(block);
    }
  }

  mtr_commit(&mtr);
}

函数逻辑说明:

drop 分区和add分区都会清空所有分区的AHI信息,最耗时的如下
循环每个分区调用函数
->btr_drop_ahi_for_table
  循环表(或者分区)中的每个索引,如果索引都没有用到AHI,
则退出
  循环innodb buffer中的每个实例,根据LRU链表循环每个page
如果page建立了AHI信息,且是要删除表(或者分区)的相关索引
  则放入drop vector容器中
如果page没有建立AHI信息 
则跳过
如果drop verctor容器中填满1024个page
则清理一次,循环每个page,调用函数
->btr_search_drop_page_hash_index
  计算page所在AHI结构的slot信息,以便找到对应的hash_table_t结构
  循环page中所有的行
    循环行中访问到的索引字段(访问模式),计算出fold信息填入到fold[]数组中
    本循环中会通过函数rec_get_offsets进行字段偏移量的获取,为耗用CPU的函数
      循环fold[]数组,一个fold代表一行数据,调用函数
       ->ha_remove_all_nodes_to_page,为耗用CPU的函数
         ->ha_chain_get_fist
           根据fold信息找到hash结构的cell
         循环本cell中的链表信息
           如果行的地址在本要删除的page上,调用函数
           ->ha_delete_hash_node,为消耗CPU的函数
             进行链表和hash结构的维护
每次处理完1024个page后,yeild线程主动放弃CPU,避免长期占用CPU,醒来后继续处理

drop 分区和add分区都会循环每个分区调用函数btr_drop_ahi_for_table 、btr_search_drop_page_hash_index清空所有分区及索引的的AHI信息, 删除第1个分区的时ahi信息被清空, 删第2个分区的时候buffer中已经没有ahi信息了,所有删除第2个分区就很快了。

避免方式

针对以上原因,线上执行 drop必须遵守以下原则:

1、关闭AHI功能,不使用AHI带来的查询加速功能,需要先在测试环境进行业务测试,确保业务性能不受影响。

2、删除表的第一个分区时,内部会清理该表在每个buffer pool实例中对应的数据块页面,耗时较久,接着删其他分区耗时很小,建议将每天一次的删除分区的操作改为每周或者每月批量执行删除分区的操作,并且需要在业务低峰期操作。

Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

image

社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html

社区2022年度勋章获奖名单: https://greatsql.cn/thread-184-1-1.html

(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)

技术交流:

image-20221030163217640

对一次drop分区引起的性能问题思考 运营商系统运维人员使用drop分区进行历史数据清理引起了一次性能问题,本文对此进行了具体的分析和思考。 立即下载

相关推荐

Cesium中实现GPU计算的泥石流地形侵蚀

通过模拟分析,可以提前识别可能发生泥石流的区域,为防灾减灾提供依据,及时发布预警,避免或减少人员伤亡和财产损失。:在建设公路、桥梁、水库等基础设施时,通过泥石流模拟分析,可以预测泥石流可能对这些设施的影响,帮助工程设计者采取合适的防护措施,确保设施的安全性。:模拟分析有助于为灾后救援工作提供科学依据,确定受灾区域的范围、救援难度等,为救援队伍制定合理的行动方案,提升救援效率。:泥石流是山区常见的地质灾害之一,通过模拟分析可以评估某一地区发生泥石流的风险,指导土地使用规划、人口迁移等决策。

weixin_43481439的博客 1320

系统优化之---分区表加速查询速度和删除速度

1、删除表里的数据最用下面语句alter table t_name drop partition p_name;alter table t_name truncate partition p_name;delete 方...

cs20080088的博客 220

【大模型微调】魔搭社区GPU进行LLaMA-Factory微调大模型自我认知

本教程介绍如何使用魔搭社区GPU资源和LLaMA-Factory工具进行大模型微调。主要内容包括环境配置、工具安装、模型训练和效果评估。通过LoRA算法进行自我认知微调,详细说明了从数据准备到模型导出的完整流程,并提供了参数调优和显存管理等实用技巧,帮助读者快速掌握大模型定制化训练方法。

LChuck的博客 2926

oracle执行drop慢,drop表空间缓慢 - Oracle专题深入讨论 - ITPUB论坛-中国专业的IT技术社区...

不好意思。最近几天都比较忙,现在继续研究。我试过单独对tab$的索引重新收集统计信息,还是不行,对tab$才能解决问题。有问题的语句如下:select u.name, o.namefromobj$ o,user$ u, tab$ t, (select obj# objnum# from tab$ where ts#=:1 andbitand(property,64+512+8192)=0...

weixin_33558958的博客 792

【DDSCAT——离散偶极近似仿真程序05】模型设计Matlab代码:多核壳球 、多核壳圆柱

简洁明了,后面及部分给出的都是模型设计的Matlab代码,这些代码都来自于一篇文章:Chin C W S. Localized Surface Plasmon Resonance with the use of Silver and Titanium Oxide Nanostructures[J]. 2011. 一、设计多个核壳球形结构 1)Matlab代码 ...

XD_Yangf的博客 4260

41-dify案例分享-基于database插件实现Text2sql的数据库查询图表工作流

本文介绍基于 Text2SQL 的 Dify 工作流实现过程。先阐述 Text2SQL 概念、步骤及应用领域。接着说明工作流制作,包括用 chatflow 加开场白、获取系统时间,配置 LLM 生成 SQL,用 SQL Execute 工具查询,经 LLM 汇总结果,代码生成 ECharts 数据,条件分支判断图表类型输出。最后介绍验证测试、提供体验地址,还提及借助工具生成建表和初始化数据 SQL 语句。

个人技术 1万+

hive ALTER TABLE DROPPARTITION

给大家整理了一些有关【IT,Hive】的项目学习资料(附讲解~~):https://edu.51cto.com/course/27963.htmlhttps://edu.51cto.com/course/31545.htmlHive 中的 ALTER TABLE DROPPARTITION 操作详解 在大数据环境下,H...

weixin_40693591的博客 790

别再用Selenium被秒封了!2026最新反爬全突破+动态渲染实战(通过率99%)

做爬虫的同学,肯定都有过这样的经历:遇到一个纯前端渲染的网站,Requests抓包只能拿到一堆空的div标签,所有数据都是JS动态生成的。这时候你想到了Selenium,结果刚打开浏览器,网站直接跳出来一个"检测到机器人访问"的页面,或者直接返回403。我之前做一个跨境电商的爬虫项目,就踩了这个大坑。一开始用默认的Selenium ChromeDriver,10次请求有9次被封,通过率不到10%。

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 1385

mysql5.7 分区表缺点_用案例分析MySQL 5.7分区表性能下降的根本原因

前言:希望通过本文,使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱,避免在该版本上继续踩坑。同时通过对源码的分享,升级MySQL5.7.18时分区表性能下降的根本原因,向MySQL源码爱好者展示分区表实现中锁的运用。问题描述MySQL 5.7版本中,性能相关的改进非常多。包括临时表相关的性能改进,连接建立速度的优化和复制分发相关的性能改进等等。基本上不需要做配置修改,只需要升级到5.7...

weixin_29672983的博客 330

YOLOv11改进策略【损失函数篇】| WIoU v3:针对低质量样本的边界框回归损失函数

是一种基于IoU的损失函数,旨在解决目标检测中边界框回归损失函数在处理低质量训练数据时的问题。论文链接:https://arxiv.org/pdf/2301.10051 源码链接:https://github.com/Instinct323/wiou此处需要查看的文件是中定义了模型的损失函数和计算方法,我们想要加入新的损失函数就只需要将代码放到这个文件内即可将下方的函数替换原本的函数即可: 用于计算各种损失。在内修改如下代码,使模型调用此损失函数。 tal.py中是一些损失函数的功能应用。在内修改如下代码,

Limiiiing的博客 3797

AgentScope 实战训练营-构建元规划智能体(Meta Planner Agent)—— 从 0 到 1 完整实现

本文介绍了基于AgentScope框架开发的元规划智能体(Meta Planner Agent)系统。该系统通过任务拆解和子代理编排机制,实现复杂任务的自动化处理。核心架构分为用户层、规划器层和子代理层,其中规划器作为"项目经理"负责任务分解、创建子代理并协调执行流程。关键技术包括AgentScope多智能体框架、DashScope大语言模型、PlanNotebook计划管理工具等。

program哲学 359

GreatSQL删除表分区特别慢的原因分析

*GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。GreatSQL删除分区慢的跟踪背景某业务系统,每天凌晨会删除分区表的一个分区(按天分区),耗时较久,从最开始的30秒,慢慢变为1分钟+,影响到交易业务的正常进行。 在测试环境进行了模拟,复现了删除分区慢的情况,本次基于GreatSQL8.0.25-17进行测试,MySQL社区版本也存在相同问题。测试环境$mysql...

老叶茶馆 364

精读204页华为的流程管理(文末附下载链接)

链接:https://pan.baidu.com/s/1eEwdBR5c0PIxkOrNhDZcGg?pwd=wha2 提取码:wha2 复制这段内容后打开百度网盘手机App,操作更方便哦。,以提升企业运营效率和竞争力,同时解决了诸多业务痛点,为华为的全球化发展提供了有力支撑。华为的流程管理对其发展起着关键作用,通过构建完善的流程体系,提升了企业运营效率与竞争力。华为的流程管理在企业发展中至关重要,其围绕。,并通过流程变革不断优化。在流程管理过程中,强调。构建了全面的流程体系。

cdfunlove的博客 282

GreatSQL社区2023全年技术文章总结

GreatSQL社区自成立以来一直致力于为广大的数据库爱好者提供一个交流与学习的平台。在2023年,我们见证了社区的蓬勃发展,见证了众多技术文章的诞生与分享。此篇总结呈现GreatSQL社区2023年社区技术文章在优快云发布的全部。这些文章涵盖了GreatSQL、MGR、源码解析、故障解析、SQL优化、安装部署、等众多数据库技术文章。

GreatSQL2021的博客 1223

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

分区表维护的常用命令:

分区表维护的常用命令: ALTER TABLE -- DROP -- PARTITION -- ADD | -- RENAME | -- MODIFITY | -- TRUNCATE | -- SPILT | -- MOVE | -- EXCHANGE | 分区索引的常用维护命令: ALTER INDEX -- DROP -- PARTITION -- REBUILD | -- RENAME | -- MODIFITY | -- SPILT | -- PARALLEL -- UNUSABLE 1、

viviliving的专栏 3910

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

GaussDB SQL执行很慢,性能低,有时长时间运行未结束

数据库经过多次删除操作后,索引页面上的索引键将被删除,造成索引膨胀。5、对表定期做vacuum full和analyze,可回收已更新或已删除的数据所占据的磁盘空间。4、分析SQL语句是否使用了不下推的函数,建议更换为支持下推的语法或函数。2、分析查询是否被阻塞,导致语句运行时间过长,可以强制结束有问题的会话。如果没有锁,查找相关业务sql,按照方法一中的判断方法进行处理。如果有锁,则查找出pid字段,使用如下函数,结束任务,释放锁。查询表大小,如果表非常大,而实际只有很少数据,那么应该执行。

D2cOneluo的博客 3885

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

ALTER TABLE 分区操作-动态增加一级,多级分区,动态删除分区

1.8.5.6 ALTER TABLE 分区操作 alter 分区操作包括增加分区和删除分区操作,这种分区操作在Spark3.x之后被支持,spark2.4版本不支持,并且使用时,必须在spark配置中加入spark.sql.extensions属性,其值为:org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions,在添加...

weixin_48370579的博客 4252

oracle执行drop慢,Oracle性能优化:drop table与db cache

【IT168 技术文档】我们都知道drop table, truncate table时都会先做一次checkpoint,将被删除对象的脏块写入磁盘。客户有一套系统,Oracle 9.2.0.8,需要做数据迁移,由于种种原因,采用的是逻辑迁移的方式。由于库比较大,超过了1.5T,而停机时间又有限,因此在正式迁移之前需要做大量的测试,测试的目的,一方面是看迁移流程上是否存在问题,另一方面是看迁移的时...

weixin_34521244的博客 1752

oracle执行drop慢,在线急等:drop table 非常慢 - Oracle数据库管理 - Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusData诗檀...

aixoracle 10.2.0.4drop一张表大概需要5s左右生成10046trace文件的问题sqlPARSING IN CURSOR #6 len=577 dep=1 uid=0 oct=3 lid=0 tim=39332565415208 hv=3360872067 ad='aaf1cad8'select u2.name, o2.name from ind$ i, obj$ o1, ob...

weixin_39792475的博客 1161

Oracle分区表drop和truncate partition索引失效问题

DBA的维护管理中,索引失效是一常见的问题,比如move、ctas、交换分区等都会造成索引的失效,以下实验是验证drop partition、truncate partition分区对本地索引和全局索引的影响,在平常中,truncate table表是不会对索引失效的。 基础环境 SQL> create table ou_part (a integer)   2  partition by

3640

alter table XXXX drop partition xxxx 不释放存储空间问题

对一个分区表进行清理,由于全是local索引,因此执行删除分区脚本 alter table xxxx drop partition xxxx; 执行完毕发现dba_free_space剩余空间没有变化。 后来发现,执行删除分区脚本必须加上update子句才能释放空间,即使没有全局索引。 alter table xxxx drop partition xxxx update global indexes; ...

weixin_37650796的博客 6246

oracle drop、truncate 分区表分区注意

由于客户某表月初通过ogg导入数据较多,ogg未能完成。因此决定使用数据泵临时导入。 停止ogg,删除表分区数据。通过delete加条件筛选数据,发现数据量较大,尝试删除,运行很长时间后,undo不够用报错。 决定,truancate该分区。查看表的分区,发现存在数个全局索引和本地索引,百度一下对分区表某分区进行drop/truncate操作。  ① 马上回收空间:   a

huoshuyinhua的专栏 2万+

ORACLE 大量删除XX表后查询变慢

大量删除XX表记录,造成数据库表查询很慢

cpz224006的专栏 1783

Oracle数据库分区表清理总结)

分区表的讲解 如何选择分区的类型,如何选择分区的列呢。在这之前你必须明确你的目的——易管理性和性能,你更注重哪个方面。分区表所影响的方面可以归类为以下几种:性能、易管理性、数据清理。  下面分别说说分区表对每一项的具体影响,  性能:  这一般是分区的主要目的。分区将大表变成了小表,当where之后的条件体现分区字段的具体值时,避免了全表扫描。  易于管理:  对于包含海量数据的大表,分区带来的易...

weixin_40581617的博客 2220

oracle truncate很慢,ORACLEl数据库truncate分区表很慢问题 | 信春哥,系统稳,闭眼上线不回滚!...

在测试环境TRUNCATE一张按天分区的大表,数据量大概30G,速度非常慢,大概需要半个小时,检查发现等待的是log file switch事件。本案例数据库版本为11.2.0.4.0,操作系统为OEL 6.5。SQL> select sql_id,OSUSER,MACHINE,TERMINAL,PROGRAM,EVENT,STATE from v$session where userna...

weixin_33873965的博客 2551
上一篇: MySQL对derived table的优化处理与使用限制
下一篇: openEuler22+GreatSQL+dbops玩转MGR
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值