function selectlocate($tarcols,$skey){
$where =""
$connector = " "
global $count
foreach($tarcols as $tarcol ){
$where .= $connector
$where .= "LOCATE('$skey', $tarcol) != 0 "
if($connector == " "){
$connector = " OR "
}
}
$sql = "SELECT * FROM pets_table WHERE $where"
$result = mysql_query($sql)
$ret = Array()
while($item = mysql_fetch_array($result, MYSQL_ASSOC)){
$count ++
$ret[] = $item
}
return $ret
}
Step 3：匹配的权重 上面Step2的结果，其实是无序的。通常，如果我们搜索一个字段：1.如果这个字段和关键字完全相同，那么一般来讲，可能这个结果应该是相关度最高的2.如果他只是其其中出现了一次，相关度就最低。3.如果他出现的次数比在其他row中出现的次数高，那么他的相关度就比2中的结果高 所以，搜索的时候依据这个顺序考虑权重，a.如果完全相等，权重为1000 b.如果出现1次，权重为10，出现n次c.权重为n*10每次搜索出来的结果附加上权重----》然后合并相同项----》并把权重累加 最后按权重排序，即可得到一个有排序的搜索结果。 以下是两种1关键字对应1个字段（上面的代码是1关键字多个字段）查询的代码（不包含合并两个数组的代码,相关的代码在Step4中），只需遍历每个关键字和字段，就能完成搜索
$count = 0
function selectequal($col,$skey){
$connector = " "
global $count
$sql = "SELECT * FROM pets_table WHERE LOWER($col)=LOWER('$skey')"
$result = mysql_query($sql)
$ret = Array()
while($item = mysql_fetch_array($result, MYSQL_ASSOC)){
$count ++
$item["weight"] = 1000
$ret[] = $item
}
return $ret
}
function selectlocate($col,$skey){
global $count
$sql = "SELECT *,(LENGTH(description) - LENGTH(REPLACE(description, '$skey', '')))/LENGTH('$skey') *10 as weight FROM pets_table WHERE LOCATE(LOWER('$skey'),LOWER($col))>0"
$result = mysql_query($sql)
$ret = Array()
while($item = mysql_fetch_array($result, MYSQL_ASSOC)){
$count ++
$ret[] = $item
}
return $ret
}
Step 4: 字段的权重 在我的需求中，显然name这个字段比description更重要，所以在匹配时，对name字段的结果应该有所倾斜，所以，又可以增加一个对字段的权重系数。1.如果是在name域的匹配，设系数为10；2.如果是在description匹配，设系数为1； 将Step 3每次计算得出的权重，再乘上这个系数，就可以得到一个新的，更有效的权重值。 最后按权重排序，即可得到一个最有相关度排序的搜索结果 其他的细节： 如果一个关键字已经满足了equal条件，那么再使用locate条件的时候会依然返回一个结果，所以在使用locate条件的时候，过滤掉equal的情况
点击(此处)折叠或打开
<?php
$count = 0
function selectequal($col,$val,$skey){
$connector = " "
global $count
$sql = "SELECT * FROM pets_table WHERE LOWER($col)=LOWER('$skey')"
$result = mysql_query($sql)
$ret = Array()
while($item = mysql_fetch_array($result, MYSQL_ASSOC)){
$count ++
$item["weight"] = 1000*$val
$ret[] = $item
}
return $ret
}
function selectlocate($col,$val,$skey){
global $count
$sql = "SELECT *,(LENGTH(description) - LENGTH(REPLACE(description, '$skey', '')))/LENGTH('$skey') *10*$val as weight FROM pets_table WHERE LOCATE(LOWER('$skey'),LOWER($col))>0 AND LOWER($col)!=LOWER('$skey')"
$result = mysql_query($sql)
$ret = Array()
while($item = mysql_fetch_array($result, MYSQL_ASSOC)){
$count ++
$ret[] = $item
}
return $ret
}
function cleanarr($arr){
global $count
$tmp = Array()
$tmpall = Array()
foreach($arr as $item){
if(array_key_exists($item['uid'], $tmp)){
$tmp[$item['uid']]+=$item["weight"]
}
else{
$tmp[$item['uid']] = $item["weight"]
$tmpall[$item['uid']] = $item
}
}
//sort by weight in descending order
arsort($tmp)
$ret = Array()
//rebuild the return arary
$count = 0
foreach($tmp as $k=>$v){
$count++
$tmpall[$k]['weight']=$v
$ret[]=$tmpall[$k]
}
return $ret
}
require_once("consvr.php")
$colshash = array("name"=>10,"description"=>1)
$ret = Array()
$keywords=explode(" ", $keywords)
$cols = array_keys($colshash)
foreach($keywords as $keyword){
foreach($colshash as $col=>$val){
$ret = array_merge($ret,selectequal($col,$val, $keyword))
$ret = array_merge($ret,selectlocate($col,$val, $keyword))
}
}
$ret = cleanarr($ret)
$ret = array('msg' => "Success", 'count'=>$count,'children' => $ret, 'query'=>"COMPLEX:NOT READABLE")
echo json_encode($ret)
mysql_close()
?>
数据分库表扩容-数据不均匀问题 原创2021-12-22 22:18:13
这是王姑娘的微博
码龄10年
关注
假如前期分三个库，一个库两个表，项目火爆，数据量激增，进行扩容
增加了新的数据库表位，会导致旧的库表比新的库表数据量多，且容易出现超载情况
解决方式思想：
不同的库表位分配的概率不一样，性能好的机器和数据量少的机器提高分配几率，类似的中间件应用场景有nginx
类似这种：
Nginx常见的负载均衡策略
节点轮询（默认）
weight 权重配置
简介：weight和访问比率成正比，数字越大，分配得到的流量越高
场景：服务器性能差异大的情况使用
upstream lbs {
server 192.168.159.133:8080 weight=5
server 192.168.159.133:8081 weight=10
}
在分库表中的加权解决方式，目前想到的几种方案：
库表位可以使用对象形式，配置权重，避免数据倾斜、数据集中(思考中...)
编写算法，根据不同的，配置权重，不同的库表位配置不同的权重(思考中...)
加权配置，list重复添加出现的高频的库表位(更改速度最快)
例如：dbPrefixList.add("0")dbPrefixList.add("1")dbPrefixList.add("a")
这三个库是第一批增加的，已经到了900多万单表量。现在准备进行扩容，那么实现方式如下:
扩容库位b,c,d
/**
* 获取随机的前缀
* @return
*/
public static String getRandomDBPrefix(){
int index = random.nextInt(dbPrefixList.size())
return dbPrefixList.get(index)
}
这样在获取随机库位的时候，0,1,a获取到的概率会低点，相对进入的数据就会少些。更多数据会进入到b ,c,d中进行平衡。
https://blog.csdn.net/weixin_43935927/article/details/109491334建立索引，要使用离散度（选择度）更高的字段。
我们先来看一个重要的属性列的 离散度，
count(distinct(column_name)) : count(*) -- 列的全部不同值个数：所有数据行行数
数据行数相同的情况下，分子越大，列的离散度就越高。简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。
当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。
创建一张商户表，因为地址字段比较长，在地址字段上建立前缀索引
create table shop(address varchar(120) not null)
alter table shop add key(address(12)) // 截取12个字符作为前缀索引是最优的吗？
问题是，截取多少呢？截取得多了，达不到节省索引存储空间的目的，截取得少了，重复内容太多，字段的散列度（选择性）会降低。怎么计算不同的长度的选择性呢？
先看一下字段在全部数据中的选择度计算公式：
select count(distinct address) / count(*) from shop
select count(distinct left(address, n)) / count(*) as subn from shop
count(distinct left(address,n)) / count(*) 的结果是会随着 n 的变大而变大。举个例子，现在有两个address（东大街长兴小区，东大街福乐小区），那么 distinct(address，2) <distinct(address，3）
==>所以，截取的长度越长就会越接近字段在全部数据中的选择度
==>所以，我们要权衡索引大小和查询速度。
举个例子，通过不同长度去计算，与全表的选择性对比：
SELECT COUNT(DISTINCT(address))/COUNT(*) sub, -- 字段在全部数据中的选择度
COUNT(DISTINCT(LEFT(address,5)))/COUNT(*) sub5, -- 截取前5个字符的选择度
COUNT(DISTINCT(LEFT(address,7)))/COUNT(*) sub7,
COUNT(DISTINCT(LEFT(address,9)))/COUNT(*) sub9,
COUNT(DISTINCT(LEFT(address,10)))/COUNT(*) sub10, -- 截取前10个字符的选择度
COUNT(DISTINCT(LEFT(address,11)))/COUNT(*) sub11,
COUNT(DISTINCT(LEFT(address,12)))/COUNT(*) sub12,
COUNT(DISTINCT(LEFT(address,13)))/COUNT(*) sub13,
COUNT(DISTINCT(LEFT(address,15)))/COUNT(*) sub15
FROM shop
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| sub | sub5 | sub7 | sub9 | sub10 | sub11 | sub12 | sub13 | sub15 |
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| 0.9993 | 0.0225 | 0.4663 | 0.8618 | 0.9734 | 0.9914 | 0.9943 | 0.9943 | 0.9958 |
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
可以看到在截取 11 个字段时 sub11(0.9993) 就已经很接近字段在全部数据中的选择度 sub(0.9958)了，而且长度也相较后面更短一些， 综合考虑比较合适。
ALTER TABLE shop ADD KEY (address(11))
1.索引的个数不要过多（浪费空间，更新变慢）
2.在用于 where 判断 order 排序和 join 的（on）字段上创建索引
3.区分度低的字段，例如性别，不要建索引（离散度太低，导致扫描行数过多）
4.更新频繁的值，不要作为主键或者索引（页分裂）
5.不建议用无序的值作为索引，例如身份z、UUID（在索引比较时需要转为ASCII，并且插入时可能造成页分裂）
6.若在多个字段都要创建索引的情况下，联合索引优于单值索引
7.联合索引把散列性高（区分度高）的值放在前面
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）