Data Archiving ERROR 1815 (HY000): Internal: Can't find a proper physical plan for this query

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 数据归档出现 ERROR 1815 (HY000): Internal : Can’t find a proper physical plan for this query

| username: zhengjunbo

[TiDB Usage Environment] Production Environment
[TiDB Version] V4.0.15
[Reproduction Path]

  1. Add
Create Table: CREATE TABLE `my_table` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',
  `post_id` varchar(32) NOT NULL DEFAULT '' COMMENT 'Order ID',
  `create_sys_tm` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time',
   PRIMARY KEY (`id`),
   KEY `idx_create_sys_tm` (`create_sys_tm`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=1 COMMENT='Order Table'

Add replica

 ALTER TABLE my_db.my_table SET TIFLASH REPLICA 1;

Export the entire database to another database without TiFlash, execute the SQL statement

explain SELECT /*!40001 SQL_NO_CACHE */  *  FROM `my_db`.`my_table` FORCE INDEX(`PRIMARY`) WHERE (create_sys_tm<'2021-09-01 00:00:00') ORDER BY `id` LIMIT 10000;    

[Encountered Problem: Problem Phenomenon and Impact]

It will directly report an error

ERROR 1815 (HY000): Internal : Can't find a proper physical plan for this query

Clearing it will work normally.

ALTER TABLE `my_db`.`my_table` SET TIFLASH REPLICA 0;
| username: tidb菜鸟一只 | Original post link

Uh, you don’t have a TiFlash cluster. If you add a TiFlash replica to the table and the execution plan goes to TiFlash, it will definitely report an error. Set the global variable tidb_allow_fallback_to_tikv = 'tiflash'; set this environment variable to prevent the execution plan from going to TiFlash…

| username: zhengjunbo | Original post link

When the data was transferred in the past, the new cluster didn’t exist. It was because we knew there was no TiFlash, which caused the issue, so we investigated the problem.

| username: 裤衩儿飞上天 | Original post link

How are you exporting the entire database?

| username: zhengjunbo | Original post link

BR import and export the entire database

| username: 裤衩儿飞上天 | Original post link

  1. Which version of BR was used for the export?
  2. Can it be reproduced?
  3. Was an analyze done after the import was completed? If not, does the error still occur after doing it?
| username: zhengjunbo | Original post link

It’s been a while, I forgot the details, but it was about BR data import, and there was an issue with analyze at that time. I checked the data consistency and didn’t pursue it further. Now, while using the archiving tool, I discovered this problem.

| username: zhengjunbo | Original post link

It should have nothing to do with analyze itself because this is a business table and they have all been analyzed.

| username: 裤衩儿飞上天 | Original post link

You can refer to this:

| username: 裤衩儿飞上天 | Original post link

If you had backed up the statistics information at that time and then completed the analyze, it might still generate the execution plan based on the previous statistics information, which could lead to the issue you encountered.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.