[Bug] 无法插入数据

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar.

### Version

1.1.2

### Describe the bug and provide the minimal reproduce step

本地环境：
系统：win11，
cpu：i5 13400
系统总内存：32G
iotdb版本：1.1.2
iotdb server配置：
confignode：
MAX_HEAP_SIZE=3072M
cn_internal_address=192.168.1.131
cn_target_config_node_list=192.168.1.131:10710
datanode：
MAX_HEAP_SIZE=3072M
dn_rpc_address=192.168.1.131
dn_internal_address=192.168.1.131
dn_target_config_node_list=192.168.1.131:10710
iotdb-common：
admin_name=xxx
admin_password=xxx
enable_auto_create_schema=false
enable_last_cache=false
query_timeout_threshold=120000
ip_white_list=127.0.0.1/32,192.168.1.131
enable_discard_out_of_order_data=true
timestamp_precision=us
time_partition_interval=31536000000

8月15日下午我使用java原生接口方式执行SessionPool#insertAlignedRecordsOfOneDevice方法把mysql数据循环插入到我本地windows版本的iotdb 1.1.2中，每次循环插入10000条record，期间运行了几个小时，我下午18:30看时还是正常插入的，等8月16日早上9:30看时插入方法已经执行完毕，接着我用SELECT count(imei) from root.bms.pi.pi_2022查询的是3563534（imei在mysql中是非null字段，一定有值，可以统计到），这个时候我发现不对劲，因为按照我的java代码来说应该要插入2000万多一点的record才对，但是实际只插入了3563534条record，然后我把8月15日的插入方法在运行了一段时间，预计应该再插入5w条数据，然后我用SELECT count(imei) from root.bms.pi.pi_2022查询发现record的条数还是3563534（time时间戳是微秒，总共16位，最后6位是随机生成的，不可能全部和已有的时间戳一样，可以排除掉时间戳相同会覆盖的情况）。最后，我把iotdb server端重启，先查询time为1637953692485879的数据不存在，接着手动插入一条time为1637953692485879的record，插入完毕后再查询一次time为1637953692485879的数据，发现还是没有，也就是没有插入成功，log_datanode_all.log的日志从8月15日我开始插入数据后到8月16日都没有一个ERROR的日志。
DBeaver客户端操作如下：
原生cli客户端操作如下：

### What did you expect to see?

希望能找出是什么问题导致的

### What did you see instead?

如上图

### Anything else?

_No response_

### Are you willing to submit a PR?

- [X] I'm willing to submit a PR!

Start with the Java SessionPool#insertAlignedRecordsOfOneDevice call and reproduce the issue against IoTDB 1.1.2 using the supplied Windows configuration and batch size. Compare insert results with SELECT count(imei) and direct CLI/DBeaver inserts, then inspect log_datanode_all.log; done means identifying a reproducible cause or a clear failing response.

Written by the indexing model from the issue text.