zhangzj

zhangzj

这家伙有点懒,还没写个性签名!

  • 财富值25
  • 威望值0
  • 总积分25

个人信息

  • 回复了 的回复

    LEFT JOIN company ON t_sales.company_id = company.id
    LEFT JOIN t_city_2 ON t_sales.t_city = t_city_2.t_id
    这里是不必要连表查的,查出id,用缓存查会效率更高,因为公司和城市这种更新不是很频繁,数据量也不是很多
    LEFT JOIN t_sales_from ON t_sales.t_from = t_sales_from.t_id
    LEFT JOIN t_sales_status ON t_sales.t_status = t_sales_status.t_id
    这也不必要连表查,多次查询,减少锁,效果会更好
    LEFT JOIN custom_category ON t_sales.t_fenlei = custom_category.id
    这个也可以用缓存查
    总的来说业务逻辑和程序设计不是很合理,建立灵活运用

    如果按以上方案,会优化不少,in是可以用到索引的,建好索引就好了,这样就差不多了

  • 补充一点,用纯数字的话只能存储 999999-99999 个数据,不一定满足数据的增长,如果加密(以用户id加密,简单算md5,从第8位开始,取8位)成6位(数字+字母)组成,可以存储62^6, 自己可以权衡下

  • 这个一定程度对敏感数据隐藏,如果是动态的就厉害了。不过太长是硬伤,自己改加密函数啰

  • LEFT JOIN company ON t_sales.company_id = company.id
    LEFT JOIN t_city_2 ON t_sales.t_city = t_city_2.t_id
    这里是不必要连表查的,查出id,用缓存查会效率更高,因为公司和城市这种更新不是很频繁,数据量也不是很多
    LEFT JOIN t_sales_from ON t_sales.t_from = t_sales_from.t_id
    LEFT JOIN t_sales_status ON t_sales.t_status = t_sales_status.t_id
    这也不必要连表查,多次查询,减少锁,效果会更好
    LEFT JOIN custom_category ON t_sales.t_fenlei = custom_category.id
    这个也可以用缓存查
    总的来说业务逻辑和程序设计不是很合理,建立灵活运用

  • 2017-04-12 已签到
    连续签到1天,获得了5个金钱
试用期 等级规则
25/50
资料完整度
10/100
用户活跃度
0/100

Ta的关注

0

Ta的粉丝

0

Ta的访客

1