除非插件切换到以不同的方式存储投票，否则就不会有基于投票进行排序的好方法。
看看投票表中的一行。
+-------------------------------------------------------+
| ID | post | votes | guests | usersinks | guestsinks |
+-------------------------------------------------------+
| 1 | 1234 | ,1,2,3 | | | |
+-------------------------------------------------------+
所有用户的投票都存储在一个单列（投票）中，MySQL没有合适的方法根据该列进行拆分、计数和排序。
也许一些MySQL忍者可以创建一个过程/函数来实现这一点，但这超出了我的SQL专业知识。
不知道作者为什么选择这样存储投票，但从结果排序的角度来看，这是一个糟糕的DB设计决策（imo）。
我很感激我没有真正解决这个问题，但我想指出这一点可能很好，虽然理论上这可能很容易，但有一个很好的理由，作者没有为这个插件提供这个功能-他的db设计使得基于投票的排序非常困难（至少在SQL级别）。
如果我写这样一个插件，我会这么做。。
使用一个新表仅保留投票，所有投票。。
表中有一些虚构的数据。
Table: wp_post_votes
Type: new
+--------------------------------------------+
| ID | post_id | user_id | type |
+--------------------------------------------+
| 1 | 123 | 10 | up |
| 2 | 123 | 22 | down |
| 3 | 123 | 4 | up |
| 4 | 123 | 1 | up |
| 5 | 25 | 6 | up |
| 6 | 25 | 10 | up |
| 7 | 25 | 1 | down |
| 8 | 25 | 2 | up |
+--------------------------------------------+
除此之外，我还使用usermeta和Posteta存储帖子和用户投票的投票计数。
这里有一些虚构的元数据来帮助可视化。
Table: wp_postmeta
Type: core, existing
+-----------------------------------------------------------+
| meta_id | post_id | meta_key | meta_value |
+-----------------------------------------------------------+
| 512 | 123 | vote_count | 4 |
| 513 | 25 | vote_count | 4 |
+-----------------------------------------------------------+
Table: wp_usermeta
Type: core, existing
+-----------------------------------------------------------+
| umeta_id | user_id | meta_key | meta_value |
+-----------------------------------------------------------+
| 443 | 1 | vote_count | 2 |
| 445 | 2 | vote_count | 1 |
| 442 | 4 | vote_count | 1 |
| 444 | 6 | vote_count | 1 |
| 440 | 10 | vote_count | 2 |
| 441 | 22 | vote_count | 1 |
+-----------------------------------------------------------+
这样一来，可以根据元值对帖子进行排序，另外利用元表意味着可以快速访问更新和获取函数，如
get_user_meta,
get_post_meta,
update_post_meta ... 等等（我相信你明白了）。
只是大声想一想，因为你的问题让我思考我应该如何做得不同。。
