表内容为100,000记录
CON_ID | CON_VALUE | CON_CATEGORY __________________________________ 001 | data1 | title 002 | data2 | title 003 | data3 | process 004 | data4 | process
我从数据库中读取数据表content
并复制到数组。因为我必须从content
中选择100次。
array(100017) {
[0]=>
array(3) {
["CON_VALUE"]=>
string(40) "data1"
["CON_ID"]=>
string(32) "001"
["CON_CATEGORY"]=>
string(9) "title"
}
[1]=>
array(3) {
["CON_VALUE"]=>
string(26) "data2"
["CON_ID"]=>
string(32) "002"
["CON_CATEGORY"]=>
string(9) "title"
}
[2]=>
array(3) {
["CON_VALUE"]=>
string(28) "data3"
["CON_ID"]=>
string(32) "003"
["CON_CATEGORY"]=>
string(9) "process"
}
[3]=>
array(3) {
["CON_VALUE"]=>
string(26) "data4"
["CON_ID"]=>
string(32) "004"
["CON_CATEGORY"]=>
string(9) "process"
}
}
例如:
我想要select CON_VALUE from Content where CON_ID=001 and CON_CATEGORY='title'
我使用foreach
foreach($GLOBALS['contentTable'] as $R)
{
if($R['CON_ID']==$id && $R['CON_VALUE']!='' && $R['CON_CATEGORY']=='PRO_TITLE' )
{
return $R["CON_VALUE"];
}
}
但是这个foreach很慢(大约10秒)
问题:如何提高搜索速度?或者有更好的方法来获得价值数组基于价值?
答案 0 :(得分:2)
由于您的foreach
循环分离并且数据库和脚本之间的大数据传输需要很长时间(正如您所注意到的),因此从数据库读取时应减少给定的结果集。
你写的是你需要从数据库中选择100次,所以我假设你意味着你需要100个不同的行。 (否则你只能选择一行并使用变量100次。)
遵循我的目标:
您问题的措辞中的第二个假设:我假设只有con_id
和con_category
的组合是唯一的。
首先,我将通过foreach
循环创建SQL语句,仅在select上创建,目标是获取类似于100行的soime:
select * from content where (con_value = 'data1' and con_category = 'title') or (con_value = 'data2' and con_category = 'title') ...
为了改进SQL优化器的工作,您还应该在两个列con_id
和con_category
上添加index
CREATE INDEX CIndex ON Content (con_id, con_category)
这应该可以改善您的选择。
如果可能,进一步改进:
1)如果con_id
是唯一的,您应该只使用IN (...)
子句选择id和this。
再次使用带有foreach的语句创建语句,或者如果可能的话,通过implode
创建基本信息(也许$idlist = implode(",", $arrayofIDs);
,以便获得
select * from content where con_id in ('001', '002')
然后,您应该为其添加唯一索引以改进搜索。如果此col是您的主键,则将其定义为此,并且默认情况下它具有唯一索引。
2)从显示的结果集中,您的con_id col是字符串。如果可以,请将con_id col更改为数值,然后执行此操作!数字搜索比字符串搜索快得多!
3)从显示的结果集中,您的con_category col是字符串,但只有键值。如果可以,请将其更改为键,以便替换" title"用1,"过程"用2等等。然后在其上创建一个索引。因为它是一个数字col而不是字符串col,你的搜索会再次得到改善。
我希望我的回答可以帮到你。我认为你可以通过改进你的SQL来实现你的目标,这样你就可以抛弃巨大的结果集。数据库端搜索100000行并不是数据库的挑战 - 这是他们的日常工作!