php 分库分表hash算法_php技巧

复制代码 代码如下:

//分库分表算法
function calc_hash_db($u, $s = 4)
{
$h = sprintf("%u", crc32($u));
$h1 = intval(fmod($h, $s));
return $h1;
}

for($i=1;$i<100;$i++)
{
echo calc_hash_db($i);
echo "<br>";
}

function calc_hash_tbl($u, $n = 256, $m = 16)
{
$h = sprintf("%u", crc32($u));
$h1 = intval($h / $n);
$h2 = $h1 % $n;
$h3 = base_convert($h2, 10, $m);
$h4 = sprintf("%02s", $h3);
return $h4;
}

时间: 2024-10-21 16:51:21

php 分库分表hash算法_php技巧的相关文章

mysql 分库分表的方法

分表后怎么做全文搜索 1.merge方式分表(不好) 2. 使用 sql union 3 使用Sphinx全文检索引擎 一,先说一下为什么要分表 当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了.分表的目的就在于此,减小数据库的负担,缩短查询时间. 根据个人经验,MySQL执行一个sql的过程如下: 1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果.在这个执行过程中最花时间在什么地方呢?第一,是排队等待的时间,第二,

水平分库分表的关键步骤和技术难点

在之前的文章中,我介绍了分库分表的几种表现形式和玩法,也重点介绍了垂直分库所带来的问题和解决方法.本篇中,我们将继续聊聊水平分库分表的一些技巧. 分片技术的由来 关系型数据库本身比较容易成为系统性能瓶颈,单机存储容量.连接数.处理能力等都很有限,数据库本身的"有状态性"导致了它并不像Web和应用服务器那么容易扩展.在互联网行业海量数据和高并发访问的考验下,聪明的技术人员提出了分库分表技术(有些地方也称为Sharding.分片).同时,流行的分布式系统中间件(例如MongoDB.Elas

MySQL分库分表的实现过程详解介绍

MySQL分库分表基础表介绍 表基本模型结构 这里我们模拟一个商城的基本的表结.此结构由(用户.门店.导购.门店商品.订单.订单对应的商品).其中,导购也是一个用户,门店是只属于一个店主的,同时店主本身也是一个导购也是一个普通用户. 结构图:   构造数据脚本 MySQL分库分表(1)-脚本 对业务场景进行模拟 场景1:购买者下订单. 1.从session中获得客户ID. 2.可以通过时间戳等拼凑一个订单ID(在创建表的时候为了方便我用自增的,在以下我们一直就吧订单ID看成不是自增的,是用程序生

水平分库分表的关键问题及解决思路

分片技术的由来 关系型数据库本身比较容易成为系统性能瓶颈,单机存储容量.连接数.处理能力等都很有限,数据库本身的"有状态性"导致了它并不像Web和应用服务器那么容易扩展.在互联网行业海量数据和高并发访问的考验下,聪明的技术人员提出了分库分表技术(有些地方也称为Sharding.分片).同时,流行的分布式系统中间件(例如MongoDB.ElasticSearch等)均自身友好支持Sharding,其原理和思想都是大同小异的. 分布式全局唯一ID 在很多中小项目中,我们往往直接使用数据库自

分库分表的几种常见玩法及如何解决跨库查询等问题

在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片"."Sharding"-这样的关键词.让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战.让人感到担忧的是,他们系统真的就需要"分库分表"了吗?"分库分表"有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议. 垂直分表 垂直分表在日常开

大众点评订单分库分表实践之路

本文是关于大众点评订单分库分表实践的一个具体分享,包含对订单库的具体切分策略,以及我个人的一些思考. 背景   订单单表早已突破两百G,因查询维度较多,即使加了两个从库,各种索引优化,依然存在很多查询不理想的情况.加之去年大量的抢购活动的开展,数据库达到瓶颈,应用只能通过限速.异步队列等对其进行保护.同时业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的DDL又非常吃力,无法达到业务要求.随着这些问题越来越突出,订单数据库的切分就愈发急迫了. 我们的目标是未来十年内不需要担心订

Mycat分库分表的简单实践

   MySQL的使用场景中,读写分离只是方案中的一部分,想要扩展,势必会用到分库分表,可喜的是Mycat里已经做到了,今天花时间测试了一下,感觉还不错. 关于分库分表     当然自己也理了一下,分库分表的这些内容,如果分成几个策略或者阶段,大概有下面的几种. 最上面的第一种是直接拆表,比如数据库db1下面有test1,test2,test3三个表,通过中间件看到的还是表test,里面的数据做了这样的拆分,能够咋一定程度上分解压力,如果细细品来,和分区表的套路有些像.   接下来的几类也是不断

透明的分库分表方案

问题提出 随着应用规模的不断扩大,单机数据库就慢慢无法满足应用的需要了,这主要表现在如下方面: 存量数据越来越大,查询速度越来越慢 访问并发越来越大,磁盘IO.网络IO.CPU都慢慢成为瓶颈 事务数越来越多,事务冲突越来越严重,导致TPS越来越少 这个时候,有的人采用了换商用数据库的方案比如Oracle,然后用Oracle的RAC方式进行水平扩展.但是带来的缺点也比较明显,第一是成本太高,一般人吃不消:第二,管理复杂度较单节点有非常大的提升,风险及管理成本也相应增加:第三,对人员的水平要求更高,

Mysql分库分表Mycat详解介绍

一直对Mysql分库分表有点兴趣,但是也一直停留在有兴趣的阶段,没有遇到能应用的场景.人生苦短,与其等一个机会,不如自己创造吧.稍微调研了下,选择使用 Mycat 这样一款开源产品.没有什么特别的理由,也不去讨论挖掘机哪家强,只是为了学习. 本机环境 电脑环境:Ubuntu 16.04 JDK:1.8 Docker version 1.11.2 Mysql 5.7.13 Mycat 1.5-RELEASE Navicat for Mysql 安装Mysql 为了测试方便,Mysql都跑在Dock