作者StupidGaGa (笨嘎嘎)
看板C_Sharp
标题[问题] C#与MySql的问题
时间Thu Dec 25 12:29:13 2014
有些问题鲁蛇的我不太清楚，想请问乡民。
1. 连线ID与指令ID？
资料库连线的时候有个连线的 thread ID，
取得的时候用 MySqlConnection.ServerThread，
这在资料库是可以观察到的。
但是公司的前辈说，
PHP内除了有连线ID可以查到之外，还有个指令的ID可以查，
是叫做Resource ID，具公司前辈说明此ID是资料库给的。
例如我同一条连线做三次查询，会像下面这样，
Thread ID : 11325, Rexource ID: 475
Thread ID : 11325, Rexource ID: 476
Thread ID : 11325, Rexource ID: 477
想请问C#如何可以查到指令的ID？
2. 多执行绪中的资料库连线该如何设计？
我知道这问题很菜，但是google我查不太到，
不知道是太菜的问题还是我关键字找错。
我到现在有三种设计，不过我觉得都有些问题
(1) 一个执行绪内有一条连线，open->指令->close、open->指令->close
(2) 一个执行绪内有一条练限，open->指令->指令->close
(3) 多个执行绪共用一条连线、用Lock，应用程式开始时open，应用程式结束close
想请各位乡民指点我一下，
又或者有可参考的书籍。
先谢谢各位有回答的乡民
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 60.249.117.38
※ 文章网址: http://webptt.com/cn.aspx?n=bbs/C_Sharp/M.1419481758.A.36C.html
1F：推 Peruheru: 连线无所谓吧，是写入才比较有lock的问题 12/25 13:34
2F：→ Peruheru: 多开几条连线应该不会怎样...吧 12/25 13:36
当多开连线时，连线过多server会将连线踢掉，
要是这时候执行指令，会导致错误，
如：
明明有该笔资料，select结果却是空的，这种神奇的事情发生，
原因是select到一半就被踢掉，所以结果当然是空的。
所以当我执行绪过多=>连线过多=>怪问题一堆。
3F：推 Peruheru: 这样阿，好吧XD 12/25 15:31
4F：推 GoalBased: 连线当然不能过多啊 不然跟被攻击有甚麽差别 12/25 15:31
5F：→ Peruheru: 那不然这样，就是独立sql查询的部分为一个执行绪 12/25 15:32
6F：→ Peruheru: 所有人的查询动作都丢到一个池内，然後sql执行绪去执行 12/25 15:33
7F：→ Peruheru: 这样永远都是同一个执行绪在使用同一条连线，没有冲突 12/25 15:33
8F：→ Peruheru: 只是变成原本sql查询的部分变成要等待执行绪执行到他们 12/25 15:34
9F：→ Peruheru: 的查询结果才行，每个人就领个号码牌等叫号 12/25 15:34
10F：→ Peruheru: 就是把SQL查询的部分独立为一个代理的意思 12/25 15:35
11F：→ Peruheru: 可能长时间未侦测到查询，就关闭连线，要用再开 12/25 15:36
12F：推 Peruheru: 甚至可以做出优先权高的查询优先执行这种事 12/25 15:44
13F：→ Peruheru: 不知道这样行不行? 12/25 15:45
基本上，作法2.(3)就已经是没问题了，不会有「神奇的事情发生」，
但2.(3)的缺点就是要让执行绪等…，
当开一两条执行绪的时候还可以接受，
当开100条执行绪，一个执行绪有20个指令，大家都共用同一个连线，大家互相等，
我觉得这样的时间耗费有点夸张。
有点左右为难
14F：推 Peruheru: 不然就像窗口一样多开几个窗口嘛 12/25 16:11
15F：→ Peruheru: 一个服务员处理不来，就多两个服务员，时间就剩三分之一 12/25 16:11
感谢你的意见，
但有些想法难以在现在的程式底下进行修改，
又或者修改的幅度太大，上头不肯接受这时间的耗费。
如果是新的程式会使用你的想法看看，谢。
16F：推 Litfal: 这得看你的多执行续是做啥、怎样设计的。 12/25 18:07
17F：→ Litfal: 一般来说我会用(1)+Connection Pool 12/25 18:08
Thx，我会去了解 Connection Pool，
顺便请问你是否可以提供一些参考方向或参考书籍？
※ 编辑: StupidGaGa (60.249.117.38), 12/26/2014 10:18:25
18F：→ Litfal: 你应该考虑控制执行续的数量，因为不是多一点执行续就会 12/26 16:59
19F：→ Litfal: 比较快，I/O bound还是在那边，甚至还会导致塞车... 12/26 17:00