If there is data in the table but not synced to ns yet, then deploying a new index can be successful

If there is data in the table, deploy a new index
If the execution is too fast, no data in the table is detected during creation, resulting in successful deployment

## Expected Behavior
ERROR: table auto_BPpPCNYd has online data, cannot deploy. please drop this table and create a new one

## Case
```yaml
-
id: 24
desc: 表有数据，deploy创建新索引
mode: standalone-unsupport
inputs:
-
columns : ["id int","c1 string","c3 int","c4 bigint","c5 float","c6 double","c7 timestamp","c8 date"]
indexs: ["index1:c3:c7"]
rows:
- [1,"aa",20,30,1.1,2.1,1590738990000,"2020-05-01"]
- [2,"aa",21,31,1.2,2.2,1590738990001,"2020-05-02"]
- [3,"aa",22,32,1.3,2.3,1590738990002,"2020-05-03"]
- [4,"aa",23,33,1.4,2.4,1590738990003,"2020-05-04"]
- [5,"aa",24,34,1.5,2.5,1590738990004,"2020-05-05"]
sqls:
- deploy deploy_{0} SELECT id, c1, sum(c4) OVER w1 as w1_c4_sum FROM {0} WINDOW w1 AS (PARTITION BY {0}.c1 ORDER BY {0}.c7 ROWS BETWEEN 2 PRECEDING AND 1 PRECEDING);
expect:
success: false
```

The issue describes a race condition where a new index deployment succeeds if table data hasn't synced to the namespace (ns) yet. Look at the deployment logic and data detection mechanisms, likely in the index creation or table sync code. The test case in the issue body provides a specific SQL and data scenario to reproduce. Start by understanding how the system checks for 'online data' during index deployment and where the sync timing window exists.

Written by the indexing model from the issue text.