胸弟，mysql分表要慎之又慎，沒有必要的情況下千萬不要貿然分庫分表。真到了非拆不可的時候，一定要結合實際業務，多花點時間做方案預研。像你們這個方案，按日期一天一張表，這完全是拍腦袋想出來的啊，給自己挖了個大坑。
按日期分表，而且是一天一張，這個方案最大的問題就是沒厘清哪些是熱點資料，哪些是歸檔資料。看你的需求，是要查七天的資料，由于你沒說清楚具體業務需求，是以有兩種情況：1.隻需要查最近七天的資料 2.可以随意查曆史某一個跨度為7天的時間段資料。
如果是情況1，你們這種拆分方案完全是畫蛇添足，因為近7天是熱點資料，隻需要在熱點表儲存近7天的資料，每天跑定時任務把上一天資料歸檔就行。一天300w，7天就是2100w，這樣一張表并不是大的不得了的規模，設計好索引，SQL寫好一點，怎麼着也比你那個幾十秒要強好多倍。另外除了拆分表，也可以用partition。
如果是情況2，沒有特定的熱點表，曆史任何一個7天跨度的資料都可能要查，這樣的需求除了BI分析，說實話我覺得真沒必要這麼幹。如果是BI分析，這麼大的資料量用mysql做從一開始就是錯的；如果是業務查詢(講道理這樣的需求真的很奇葩)，得看用什麼次元查，舉個例子電商網站使用者查自己的曆史訂單，這樣的需求應該用userID取模做水準拆分，而不是用日期。總之這樣的情況還需要具體問題具體分析，沒有一成不變的方案。如果業務要求可以用任何一個次元查，按目前這種情況，恐怕沒什麼好方案了，每一次查詢都需要跨多張表，非要做的話，也不能用union all這種最粗暴的辦法，可以嘗試多開幾個線程，每個線程查一張表，并行着來，然後在記憶體中把多個結果集重新組合排序，如果CPU好點的話，理論上能快不少。
再退一萬步，如果還是不行，就考慮上ES吧。不過那就是另外一個故事了。