1.实际场景：
数据库中订单表是公用的，所有用户在一张订单表上。
怎么让每个用户的订单编号是独立的命名空间？比如用户A下了两张订单，他的订单编号应该是C001、C002，用户B下了三张订单，他的编号起始位置应该还是C001，而不是C003，他的所有订单编号应该是C001,C002,C003。
请问怎么做到这一点？
难道要在每个用户底下存一个他当前开了多少个订单的字段，然后每次先读出来，加一，再存回去？这不太好吧……有没有更好的方法，在数据库端就做了？好像听人说起过用数据库函数或者触发器？
2.如果数据库能做到上述这一点，请问这个C001一般是存在主键字段里么？还是主键依然是一个数字类型的递增主键，只是在表中增加一个字段去存这个C001？
注：是在Mysql数据库中。
1.实际场景：
数据库中订单表是公用的，所有用户在一张订单表上。
怎么让每个用户的订单编号是独立的命名空间？比如用户A下了两张订单，他的订单编号应该是C001、C002，用户B下了三张订单，他的编号起始位置应该还是C001，而不是C003，他的所有订单编号应该是C001,C002,C003。
请问怎么做到这一点？
难道要在每个用户底下存一个他当前开了多少个订单的字段，然后每次先读出来，加一，再存回去？这不太好吧……有没有更好的方法，在数据库端就做了？好像听人说起过用数据库函数或者触发器？
2.如果数据库能做到上述这一点，请问这个C001一般是存在主键字段里么？还是主键依然是一个数字类型的递增主键，只是在表中增加一个字段去存这个C001？
注：是在Mysql数据库中。
1：数据库中不用那样存，你只需要遍历出来所有定单之后，显示时按顺序就行了。
2：给每个用户属性中增加静态成员变量，并且数据库中相应增加字段，每次加入的数据就是你说的样子了。
楼主的意思应该是建立不同客户账户的统一订单管理库，不同账户只能看到属于自己的订单，有点类似云erp。
订单表可以冗余一个主键id，在数据存储唯一性上面，可以看为订单code+用户id来唯一确认一条数据。
如果说需要表结构优化设计的话，可以根据每个用户自动建立一张订单表，将每个用户的订单数据独立出来，表名类似order_userid 每次根据用户找到对应表名取数据，但在最后的综合后台对所有用户订单数据统计可能会稍微麻烦些。
请问你如何保证订单的唯一
如果根据题述意思设计数据库，则仅查找订单这一操作就将出现异常。因为我们根据订单号无法确定唯一订单。
主键的值用于唯一地标识表中的某一条记录。
（关于你的项目
我建议：
订单这张表的主键可以是OrderId
而用户表的主键可以是UserId
我认为您的问题应该出在数据库表的基本理解上。建议阅读数据库规范化的相关内容。)
用一个orderid表存放所有用户下一个order的id，如果觉得麻烦建议你用时间作为订单号的一部分。
不能作为主键，主键设计有一个原则——必须是和业务无关的。所以主键永远都是无意义的自增ID之类的。
我看不出你这个问题是要解决什么实际的需求
表结构的设计，要遵守最基本的三个范式的要求。三个范式的目的，是要保证字段之间不要有冗余，不要有依赖。上面几位说的问题，我就不重复了，你这样设计，违反了数据库表结构设计的三大范式的原则，建议你好好理清楚需求，不应该做这样的设计，或者我们理解错了，你把问题重新表述一番。或者直接贴出你的建表语句来。
可以使用联合主键将uid和cid组合起来，这就就可以保证唯一性了。但要注意如下两点:
1、要使用mysql联合主键自增，需使用MyISAM作为存储引擎。
2、使用联合 主键自增的时候，自增键不能是主键最左的键。
order表里面增加一个user_owner_order_key，然后自己写代码处理 C001 这种东西与真实order_id之间的互换逻辑就行了。
<code>//伪码 $user_owner_order_id = (select count(*) from order where user = $uid and order_id </code>
说一个其他方面的问题，一般的第三方支付对于同一个订单号是无法多次付款的，所以最好考虑清楚要不要这样做。
用户表可以有一个字段存放订单数量，每次有新订单就取这个值加一，然后更新回去；
新订单获取已有订单的条数，加一，不过这个删除订单的时候必须是软删除了
