由來

這個問題戳到了Django ORM的痛點，對於多資料庫/分庫的問題，Django提供了很好的支援，通過using和db router可以很好的完成多資料庫的操作。但是說到分表的問題，就有點不那麼友好了。但也不是那麼難處理，只是處理起來不太優雅。

解析

在Django中，資料庫訪問的邏輯基本上是在Queryset中完成的，一個查詢請求，比如：User.objects.filter(group_id=10)。

其中的objects其實就是models.Manager，而Manager又是對QuerySet的一個包裝。而QuerySet又是最終要轉換為sql的一箇中間層（就是ORM種，把Model操作轉換為SQL語句的部分）。所以當我們寫下User.objects

1. classUser(models.Model):
2. username = models.CharField(max_length=255)
3. classMeta:
4. db_table ='user'

理論上講，我們可以通過在執行時修改db_table來完成分表CRUD的邏輯，但是the5fire在看了又看原始碼之後，還是沒找到如何下手。還是上面的問題，當執行到User.objects的時候，表已經確定了，當執行到User.objects.filter(group=10)的時候只不過是在已經生成好的sql語句中增加了一個where部分語句。所以並沒有辦法在執行filter的時候來動態設定db_table。

對於問題中說的get也是一樣，因為get本身就是在執行完filter之後從_result_cache列表中獲取的資料（_result_cache[0]）。

方案一

根據the5fire上面的分析，要想在執行具體查詢時修改db_table已經是不可能了（當然，如果你打算去重寫Model中Meta部分的邏輯以及Queryset部分的邏輯，就當我沒說，我只能表示佩服）。

所以只能從定義層面下手了。也就是我需要定義多個Model，同樣的欄位，不同的db_table。大概是這樣。

1. classUser(models.Model):
2. username = models.CharField(max_length=
   255)
3. classMeta:
4. abstract=True
5. classUser1(User):
6. classMeta:
7. db_table ='user_1'# 預設情況下不設定db_table屬性時，Django會使用``<app>_<model_name>``.lower()來作為表名
8. classUser2(User):
9. classMeta:
10. db_table ='user_2'

這樣在User.objects.get(id=3)的時候，如果按照模2計算，那就是User01.objects.get(id=3)，笨點的方法就是寫一個dict:

1. user_sharding_map ={
2. 1:User1,
3. 2:User2
4. }
5. def get_sharding_model(id):
6. key = id %2+1
7. return user_sharding_map[key]
8. ShardingModel= get_sharding_model(3)
9. ShardingModel.objects.get(id=3)

如果真的這麼寫那Python作為動態語言，還有啥用，你分128張表試試。我們應該動態創建出User01,User02,....UserN這樣的表。

1. classUser(models.Model):
2. @classmethod
3. def get_sharding_model(cls, id=None):
4. piece = id %2+1
5. classMeta:
6. db_table ='user_%s'% piece
7. attrs ={
8. '__module__': cls.__module__,
9. 'Meta':Meta,
10. }
11. return type(str('User%s'% piece),(cls,), attrs)
12. username = models.CharField(max_length=255, verbose_name="the5fire blog username")
13. classMeta:
14. abstract=True
15. ShardingUser=User.get_sharding_model(id=3)
16. user =ShardingUser.objects.get(id=3)

嗯，這樣看起來似乎好了一下，但是還有問題，id=3需要傳兩次，如果兩次不一致，那就麻煩了。Model層要為上層提供統一的入口才行。

1. classMyUser(models.Model):
2. # 增加方法 BY the5fire
3. @classmethod
4. def sharding_get(cls, id=None,**kwargs):
5. assert id,'id is required!'
6. Model= cls.get_sharding_model(id=id)
7. returnModel.objects.get(id=id,**kwargs)

對上層來書，只需要執行MyUser.sharding_get(id=10)即可。不過這改變了之前的呼叫習慣 objects.get 。

不管怎麼說吧，這也是個方案，更完美的方法就不繼續探究了，在Django的ORM中鑽來鑽去尋找可以hook的點實在憋屈。

我們來看方案二吧

方案二

ORM的過程是這樣的，Model——> SQL ——> Model，在方案一中我們一直在處理Model——> SQL的部分。其實我們可以拋開這一步，直接使用raw sql。

QuerySet提供了raw這樣的介面，用來讓你忽略第一層轉換，但是有可以使用從SQL到Model的轉換。只針對SELECT的案例:

1. classMyUser(models.Model):
2. id = models.IntegerField(primary_key=True, verbose_name='ID')
3. username = models.CharField(max_length=255)
4. @classmethod
5. def get_sharding_table(cls, id=None):
6. piece = id %2+1
7. return cls._meta.db_table + str(piece)
8. @classmethod
9. def sharding_get(cls, id=None,**kwargs):
10. assert isinstance(id,int),'id must be integer!'
11. table = cls.get_sharding_table(id)
12. sql ="SELECT * FROM %s"% table
13. kwargs['id']= id
14. condition =' AND '.join([k +'=%s'for k in kwargs])
15. params=[str(v)for v in kwargs.values()]
16. where=" WHERE "+ condition
17. try:
18. return cls.objects.raw(sql +where,params=params)[0]# the5fire:這裡應該模仿Queryset中get的處理方式
19. exceptIndexError:
20. # the5fire:其實應該拋Django的那個DoesNotExist異常
21. returnNone
22. classMeta:
23. db_table ='user_'

大概這麼個意思吧，程式碼可以再嚴謹些。

總結

單純看方案一的話，可能會覺得這麼大量資料的專案，就別用Django了。其實the5fire第一次嘗試找一個優雅的方式hack db_table時，也是一頭灰。但是，所有的專案都是由小到大的，隨著資料/業務的變大，技術人員應該也會更加了解Django，等到一定階段之後，可能發現，用其他更靈活的框架，跟直接定製Django成本差不多。

參考連結:

https://www.the5fire.com/django-sharding-model.html