c*d
2 楼
刚回国，回来后H1b visa 的PED 是今年7月，我的I797上面2015年才过期。怎么办？难
道只能在美国待3个月？
道只能在美国待3个月？
b*l
3 楼
《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
那梦中岂不更要小心？
经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
那谁，你看，你看。
那梦中岂不更要小心？
经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
那谁，你看，你看。
C*g
4 楼
我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
用文件系统？
记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
用文件系统？
m*i
5 楼
不会有人理的，没见他们理过谁。
I*d
6 楼
that's normal, just based on 797 expiration date
【在 c****d 的大作中提到】
: 刚回国，回来后H1b visa 的PED 是今年7月，我的I797上面2015年才过期。怎么办？难
: 道只能在美国待3个月？
【在 c****d 的大作中提到】
: 刚回国，回来后H1b visa 的PED 是今年7月，我的I797上面2015年才过期。怎么办？难
: 道只能在美国待3个月？
A*e
7 楼
赞出轨 ：D
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
g*g
8 楼
什么查询，建索引了没有？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
wh
9 楼
是啊我也一眼看到“梦见出轨”……
让谁看？看啥？
【在 A*********e 的大作中提到】
: 赞出轨 ：D
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
让谁看？看啥？
【在 A*********e 的大作中提到】
: 赞出轨 ：D
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
l*n
10 楼
文本查询还是es快吧。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
p*e
11 楼
那谁，快来看，河马意欲与你共会周公，于梦中恣意放纵
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
T*9
12 楼
用elastic search吧
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
b*l
13 楼
～～～>_都什么人啊，这是。。。
另，想起了周公之礼。。。
【在 p*****e 的大作中提到】
: 那谁，快来看，河马意欲与你共会周公，于梦中恣意放纵
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
另，想起了周公之礼。。。
【在 p*****e 的大作中提到】
: 那谁，快来看，河马意欲与你共会周公，于梦中恣意放纵
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
C*g
14 楼
有chapterid和bookid作为索引。下面是一个查询例子：
BBC_Chapter是保存chapter基本信息的表
BBC_Content是保存chapter内容的表
select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
1004';
【在 g*****g 的大作中提到】
: 什么查询，建索引了没有？
:
: EC2
BBC_Chapter是保存chapter基本信息的表
BBC_Content是保存chapter内容的表
select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
1004';
【在 g*****g 的大作中提到】
: 什么查询，建索引了没有？
:
: EC2
p*e
15 楼
娃哈哈，这可是你自己说的
【在 b*****l 的大作中提到】
: ～～～>_: 都什么人啊，这是。。。
: 另，想起了周公之礼。。。
【在 b*****l 的大作中提到】
: ～～～>_: 都什么人啊，这是。。。
: 另，想起了周公之礼。。。
n*t
16 楼
chapterstatus 加个索引试试，不过应该是物理硬盘的问题，content 需要读出来，你
需要检查一下 output data size，或者 select 里去掉 content 比较一下。
另外，为什么是 LEFT JOIN？
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
需要检查一下 output data size，或者 select 里去掉 content 比较一下。
另外，为什么是 LEFT JOIN？
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
S*f
17 楼
那谁是谁
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
藏的龙，心中的霓霞飞舞，心念的恣意放旷。
，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
。真是可以笑出眼泪的妙语。
【在 b*****l 的大作中提到】
: 《大学》说，要慎独，独处无人时，最要谨小慎微，要小心自己的心，心里卧的虎，藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: 那梦中岂不更要小心？
: 经常梦见在高速上失控，梦见横着滑过一条条的 lanes，高速撞上护栏或者翻下山坡，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 想起那个老笑话了：做梦，梦见在开车时睡觉，就吓醒了，发现果然在开车。
: 在想，会不会有一天，又梦见失控出轨，突然吓醒，发现一切都是真的？
: 是不是连这样的梦都不要去惹？是不是连梦中都要谨小慎微，如履薄冰？
: 张潮在《幽梦影》中说：庄周梦为蝴蝶，庄周之幸也；蝴蝶梦为庄周，蝴蝶之不幸也。真是可以笑出眼泪的妙语。
: 那谁，你看，你看。
g*g
18 楼
where里把 id提到第一个，把 结果里的 content去掉，如果快就是 IO问题，得升
instance.
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
instance.
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
l*r
19 楼
imaginary friend
【在 S*********f 的大作中提到】
: 那谁是谁
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
【在 S*********f 的大作中提到】
: 那谁是谁
:
: 藏的龙，心中的霓霞飞舞，心念的恣意放旷。
: ，好在总能及时控制住梦中的情节，说：不算，再来。然后重新梦起。
: 。真是可以笑出眼泪的妙语。
n*t
20 楼
他这个 where clause order 根本没关系，只跟 index 有关，不懂别瞎说
【在 g*****g 的大作中提到】
: where里把 id提到第一个，把 结果里的 content去掉，如果快就是 IO问题，得升
: instance.
【在 g*****g 的大作中提到】
: where里把 id提到第一个，把 结果里的 content去掉，如果快就是 IO问题，得升
: instance.
n*w
21 楼
execution plan?
这个query不瞬间拿到结果肯定有问题。index 或 vm。
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
这个query不瞬间拿到结果肯定有问题。index 或 vm。
【在 C********g 的大作中提到】
: 有chapterid和bookid作为索引。下面是一个查询例子：
: BBC_Chapter是保存chapter基本信息的表
: BBC_Content是保存chapter内容的表
: select BBC_Chapter.chapterid, BBC_Chapter.bookid, title, chaptertype,
: content from BBC_Chapter left join BBC_Content on BBC_Chapter.chapterid =
: BBC_Content.chapterid where chapterstatus = 0 and BBC_Chapter.bookid = '
: 1004';
e*2
22 楼
用lucene，luke。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
g*t
23 楼
chapterstatus加索引，where里的字段都加index，
google搜索快，是全文索引，网页里每个word都索引，狗狗的特长就是这些索引数据的
存储，读取，
就是今天大数据的起源，
google搜索快，是全文索引，网页里每个word都索引，狗狗的特长就是这些索引数据的
存储，读取，
就是今天大数据的起源，
i*i
24 楼
只查 BBC_Chapter 需要多长时间？
select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
= '
1004';
select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
= '
1004';
k*3
25 楼
mysql 有 index hint
C*g
26 楼
0.00 sec
bookid
【在 i**i 的大作中提到】
: 只查 BBC_Chapter 需要多长时间？
: select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
: = '
: 1004';
bookid
【在 i**i 的大作中提到】
: 只查 BBC_Chapter 需要多长时间？
: select ＊ from BBC_Chapter where chapterstatus = 0 and BBC_Chapter.bookid
: = '
: 1004';
B*g
27 楼
tuning SQL 不贴execution plan神仙也没辙呀
i*i
28 楼
select a.chapterid from BBC_Chapter as a, BBC_Content where BBC_Chapter.
chapterid =
BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
需要多长时间？
chapterid =
BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
需要多长时间？
C*g
29 楼
15.88 sec.
【在 i**i 的大作中提到】
: select a.chapterid from BBC_Chapter as a, BBC_Content where BBC_Chapter.
: chapterid =
: BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
: 需要多长时间？
【在 i**i 的大作中提到】
: select a.chapterid from BBC_Chapter as a, BBC_Content where BBC_Chapter.
: chapterid =
: BBC_Content.chapterid and BBC_Chapter.bookid = '1004';
: 需要多长时间？
i*i
30 楼
你确定content的那个id有index?
【在 C********g 的大作中提到】
: 15.88 sec.
【在 C********g 的大作中提到】
: 15.88 sec.
C*g
31 楼
是这个吗？
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_
len | ref | rows | filtered | Extra |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| 1 | SIMPLE | BBC_Content | ALL | NULL | NULL | NULL
| NULL | 70254 | 100.00 | |
| 1 | SIMPLE | a | eq_ref | PRIMARY,bookid | PRIMARY | 4
| BBC.BBC_Content.chapterid | 1 | 100.00 | Using where |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
2 rows in set, 1 warning (0.01 sec)
【在 B*****g 的大作中提到】
: tuning SQL 不贴execution plan神仙也没辙呀
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_
len | ref | rows | filtered | Extra |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
| 1 | SIMPLE | BBC_Content | ALL | NULL | NULL | NULL
| NULL | 70254 | 100.00 | |
| 1 | SIMPLE | a | eq_ref | PRIMARY,bookid | PRIMARY | 4
| BBC.BBC_Content.chapterid | 1 | 100.00 | Using where |
+----+-------------+-------------+--------+----------------+---------+------
---+---------------------------+-------+----------+-------------+
2 rows in set, 1 warning (0.01 sec)
【在 B*****g 的大作中提到】
: tuning SQL 不贴execution plan神仙也没辙呀
C*g
32 楼
谢谢你的提醒。犯了个低级错误，把index搞混淆了。
【在 i**i 的大作中提到】
: 你确定content的那个id有index?
【在 i**i 的大作中提到】
: 你确定content的那个id有index?
d*n
33 楼
瞎说一下啊，鄙人根本没经验。
除了content 以外的查询用rdbms,
content search 再另建一个nosql 用mapreduce 专门干这个。
这个非常适合read 多于write情况。
不好的地方就是额外的存储开销和save content 时候要建立 nosql delay
keyWords occur rdbms-indexId?
黄容 100 idx0
郭靖 85 idx17
避血剑 50 index 55
然后对 sentence 展开，我估计肯定有专门干这个的轮子，不用自己造
除了content 以外的查询用rdbms,
content search 再另建一个nosql 用mapreduce 专门干这个。
这个非常适合read 多于write情况。
不好的地方就是额外的存储开销和save content 时候要建立 nosql delay
keyWords occur rdbms-indexId?
黄容 100 idx0
郭靖 85 idx17
避血剑 50 index 55
然后对 sentence 展开，我估计肯定有专门干这个的轮子，不用自己造
i*i
34 楼
说好的每人一个包子呢？
【在 C********g 的大作中提到】
: 谢谢你的提醒。犯了个低级错误，把index搞混淆了。
【在 C********g 的大作中提到】
: 谢谢你的提醒。犯了个低级错误，把index搞混淆了。
i*i
35 楼
谢谢包子
【在 i**i 的大作中提到】
: 说好的每人一个包子呢？
【在 i**i 的大作中提到】
: 说好的每人一个包子呢？
w*g
36 楼
我这里最大的表是259G，而且每条记录就几十个字节，ID都是64位的。几乎每秒钟都在
增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
mongodb和文件系统都救不了你。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
mongodb和文件系统都救不了你。
EC2
【在 C********g 的大作中提到】
: 我K在网上采集了大约2500部小说，所有的内容都存在一个mysql table里面，每章一条
: 记录，总共才70K的记录，1.3G大小，但一个简单的查询竟然需要15秒。我用的AWS EC2
: 最基本的那个服务器，免费一年的那个。最终的数据库大小会在10GB左右。请问有什么
: 优化的方法可以让我继续使用mysql？如果没有，不知道MongoDB可不可以？或者必须采
: 用文件系统？
C*g
37 楼
就一个mysql server instance?
【在 w***g 的大作中提到】
: 我这里最大的表是259G，而且每条记录就几十个字节，ID都是64位的。几乎每秒钟都在
: 增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
: mongodb和文件系统都救不了你。
:
: EC2
【在 w***g 的大作中提到】
: 我这里最大的表是259G，而且每条记录就几十个字节，ID都是64位的。几乎每秒钟都在
: 增删查改，也没啥性能问题。不要对mysql的速度有任何怀疑。如果mysql不够快了，
: mongodb和文件系统都救不了你。
:
: EC2
d*n
38 楼
同问
【在 C********g 的大作中提到】
: 就一个mysql server instance?
【在 C********g 的大作中提到】
: 就一个mysql server instance?
w*g
39 楼
就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
你那个索引文本的可能是用错轮子了。
【在 C********g 的大作中提到】
: 就一个mysql server instance?
存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
你那个索引文本的可能是用错轮子了。
【在 C********g 的大作中提到】
: 就一个mysql server instance?
d*n
40 楼
你这是vertical scale up 了？
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
w*z
41 楼
一秒几次操作？
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
【在 w***g 的大作中提到】
: 就一个server instance，给40G内存。 挂一个远程slave做HA，不过主服务器超稳定，
: 存储是拿两个3T硬盘搭的soft raid1, 硬盘坏过，raid抗下来了。HA从来就没有发挥
: 过作用。当然我的应用不一样，优化得比较好。做了分表，每个操作可以确保落在一
: 两个分表上。每个分表30G的样子，上面有各种索引。CPU负载不到10%。
: 你那个索引文本的可能是用错轮子了。
w*g
42 楼
一两秒钟一次吧。有时候一秒一两次。不是很频繁。
【在 w**z 的大作中提到】
: 一秒几次操作？
【在 w**z 的大作中提到】
: 一秒几次操作？
g*g
43 楼
难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
【在 w***g 的大作中提到】
: 一两秒钟一次吧。有时候一秒一两次。不是很频繁。
【在 w***g 的大作中提到】
: 一两秒钟一次吧。有时候一秒一两次。不是很频繁。
N*m
44 楼
试过aurora没？
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
w*g
45 楼
震撼你一下
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
我们那种行业应用比不得你们做consumer market的，每秒5k个。
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
我们那种行业应用比不得你们做consumer market的，每秒5k个。
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
g*g
46 楼
我们有的应用处理的是每秒百万次写，只不过不往 RDBMS上放。
【在 w***g 的大作中提到】
: 震撼你一下
: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
: SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
: 我们那种行业应用比不得你们做consumer market的，每秒5k个。
【在 w***g 的大作中提到】
: 震撼你一下
: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
: SPARC-T5-8 Server, tpmC 8,552,523. 每秒14w个transaction。
: 我们那种行业应用比不得你们做consumer market的，每秒5k个。
w*z
47 楼
我们最忙的mysql 是4K/ seconds， cpu 还不到10%。 当然我们自己的DB server 比较
强劲, 24core, 128G memory.
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
强劲, 24core, 128G memory.
【在 g*****g 的大作中提到】
: 难怪了。我们在RDS里大约5K/s操作还行，再往上就开始timeout了。
g*g
48 楼
我们在 AWS上没用最贵的 instance，还有空间。
【在 w**z 的大作中提到】
: 我们最忙的mysql 是4K/ seconds， cpu 还不到10%。 当然我们自己的DB server 比较
: 强劲, 24core, 128G memory.
【在 w**z 的大作中提到】
: 我们最忙的mysql 是4K/ seconds， cpu 还不到10%。 当然我们自己的DB server 比较
: 强劲, 24core, 128G memory.
相关阅读
突破网络枷锁update 20150420做gui的eclipse rcp有人用过么vert.x 上写coffeescript?选哪个？ CS Masters at Columbia vs Rutgers为什么我觉得c++比java简单?王垠 怎样尊重一个程序员也谈“怎样尊重一个程序员”请问什么工具包可以做词频统计但是能略过无意义的虚词？Jenkins 的 Rest API 能否提供build是否完成的信息?java里run curl system command的问题IT职业困惑咨询机器学习臭牛逼啥slack got hacked， 没一个安全的Linus在狗狗能干过jeff dean,我看不一定。。。同时写两个平台的app？用swift 开发andriod阿里巴巴硅谷办公室做什么？感觉Scala要火大家用什么putty tab工具？现在的趋势是广好还是专好