2015年9月15日 星期二
PHP laravel虛擬機器建構 WINDOWS版
1.安裝VirtualBox-5.0.2-102096-Win.exe
2.安裝Vagrant.
3.打開cmd 執行 vagrant box add laravel/homestead
4.GIT 克隆https://github.com/laravel/homestead.git
建議建在C:\Users\XXXX\homestead\
5.到克隆出來的資料夾執行init.sh
6.建立金鑰，在C:\Users\XXXX\homestead\直接按右鍵Git Bash 執行ssh-keygen -t rsa -C username
7.修改C:\Users\XXXX\.homestead\Homestead.yaml
(基本上~代表C:\Users\XXXX\)authorize、keys、folders、sites基本上我都有修改，要注意此檔案非常挑剔，多空一行都有可能會vagrant up不成功
8.隨意GIT下載一個laravel專案到上面folders裡面
EX:在C:\Users\XXXX\PHP\裡面克隆https://github.com/laravel/laravel.git
9.在CMD裡C:\Users\XXXX\homestead\裡面執行vagrant up基本上就可以跑了
10.若要登入帳號以及密碼都是vagrant(強烈建議使用pietty或是puetty登入)
11.開新專案請使用Composer ，在虛擬機直接執行composer global require "laravel/installer=~1.1"一旦安裝完成後，就可以使用 laravel new 指令建立一份全新安裝的 Laravel 專案，例如：laravel new blog 將會在當前目錄下建立一個叫 blog 的目錄(此步驟我是SSH進去虛擬機做，因為Composer在WINDOWS下使用需要安裝PHP)
連接資料庫
在 Homestead 中，已經預裝了 MySQL 與 Postgres 兩種資料庫。為了方便使用，Laravel 在 local 的資料庫設定值中已經預設將其設定完成。
如果想要從本機電腦上透過 Navicat 或者是 Sequel Pro 連接 MySQL 或 Postgres 資料庫，你可以連接 127.0.0.1(192.168....) 的連接埠 33060 (MySQL) 或 54320 (Postgres)。而帳號密碼分別是 homestead / secret
常用的vagrant指令
啟用虛擬機器
$ vagrant up
關閉虛擬機器
$ vagrant halt
重新讀取yaml設定檔並重新啟動
$ vagrant provision
使用ssh連線到虛擬主機(WINDOWS想像沒辦法使用，請用其他連接SSH軟體)
$ vagrant ssh
失敗筆記:WIN7裝vmware開不起來虛擬機(全部刪掉)
2015年8月6日 星期四
ASP.NET ScriptResource.axd ERROR
ASP.NET ScriptResource.axd發生錯誤
WEB有做L4會產生的問題
不同機器加密時自動產生的金鑰不同，
解決的辦法就是在WebConfig裡指定machine key的加解密方法
* 放在...
decryptionKey="A69D80B92A16DFE1698DFE86D4CED630FA56D7C1661C8D05744449889B88E8DC"
validation="SHA1" decryption="AES"
/>
線上自動產生machineKey:
2014年1月7日 星期二
2013年12月1日 星期日
JS 非同步
在HTML5中，script標籤多了許多屬性，async 就是其中之一。
async屬性可以讓javascript進行非同步的載入跟執行，而不會停止網頁其他部分的載入與解析。
這種讓外部js擋在背景載入與執行的方法，大大的提升了網頁載入與執行的效能。
雖然只適用於外部js檔，但實用性相當高，以後網頁要添加一些小工具，像是月曆之類的。
也就不用過於害怕添加太多而導致網頁載入被拖垮了。
async 屬性 與 defer屬性合用會有下列幾種：
1.async與defer屬性皆不存在：
同步下載與執行，這種作法會讓瀏覽器停止對網頁的解析，直到js檔執行完畢為止，
對網頁效能有顯著的負面影響。
2.async屬性存在：
非同步下載與執行，程式碼在下載完後會立即執行。下載與執行都在背景執行，
不影響網頁本身的解析。有顯著的效能提升。
3.defer屬性存在：
js檔會在背景下載，並在網頁解析完成後才開始執行。
4.async與defer皆存在：
優先使用ansyc，而忽略defer，如果瀏覽器對ansyc不支援，那會使用defer屬性。
上面我都用 "存在" 這字眼，原因之一是HTML5的原文是使用 " present" ，
另外一個原因是因為，IE並不理會HTML5中ansyc與defer皆是boolean值的規定。
只要有ansyc字眼出現，他就認為是要非同步下載執行。
所以說下面幾個寫法對IE而言都是一樣的。
相關文章中還有一些關於HTML5的發展消息，可以參考一下。
async屬性可以讓javascript進行非同步的載入跟執行，而不會停止網頁其他部分的載入與解析。
這種讓外部js擋在背景載入與執行的方法，大大的提升了網頁載入與執行的效能。
雖然只適用於外部js檔，但實用性相當高，以後網頁要添加一些小工具，像是月曆之類的。
也就不用過於害怕添加太多而導致網頁載入被拖垮了。
async 屬性 與 defer屬性合用會有下列幾種：
1.async與defer屬性皆不存在：
同步下載與執行，這種作法會讓瀏覽器停止對網頁的解析，直到js檔執行完畢為止，
對網頁效能有顯著的負面影響。
2.async屬性存在：
非同步下載與執行，程式碼在下載完後會立即執行。下載與執行都在背景執行，
不影響網頁本身的解析。有顯著的效能提升。
3.defer屬性存在：
js檔會在背景下載，並在網頁解析完成後才開始執行。
4.async與defer皆存在：
優先使用ansyc，而忽略defer，如果瀏覽器對ansyc不支援，那會使用defer屬性。
上面我都用 "存在" 這字眼，原因之一是HTML5的原文是使用 " present" ，
另外一個原因是因為，IE並不理會HTML5中ansyc與defer皆是boolean值的規定。
只要有ansyc字眼出現，他就認為是要非同步下載執行。
所以說下面幾個寫法對IE而言都是一樣的。
2011年9月22日 星期四
Sql查询执行效率
sql查询执行效率条件中最好不要使用OR 或IN )
1.有索引的列优先，都有索引的看查询出来的数据量，少的优先
in ,not in,<>,is null,is not null 等由于不会走索引，尽量不要使用。
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1K以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1K以下'
以 上两个SQL中dy_dj及xh_bz两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的 比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
2.选择最有效率的表名顺序
sql解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表
如果tab2中记录数明显高于tab1，用
SELECT COUNT(*) FROM tab2, tab1
效率明显优于
SELECT COUNT(*) FROM tab1, tab2
1、操作符号： NOT IN操作符
此 操作是强列推荐不使用的，因为它不能应用表的索引。推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替 "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", "LIKE '%500'"，因为他们不走索引全是表扫描。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作. 如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
2、注意union和union all的区别。union比union all多做了一步distinct操作。能用union all的情况下尽量不用union。
3、查询时尽量不要返回不需要的行、列。另外在多表连接查询时，尽量改成连接查询，少用子查询。
4、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用存储过程来代替它。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。
我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，
直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
5、创建合理的索引，对于插入或者修改比较频繁的表，尽量慎用索引。因为如果表中存在索引，插入和修改时也会引起全表扫描。
索引一般使用于where后经常用作条件的字段上。
6、在表中定义字段或者存储过程、函数中定义参数时，将参数的大小设置为合适即可，勿设置太大。这样开销很大。
7、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。
select * from chineseresume where title in ('男','女')
Select * from chineseresume where between '男' and '女'是一样的。由于in会在比较多次，所以有时会慢些。
8、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
9、WHERE后面的条件顺序影响
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以 上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，如果dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的 比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。所以尽量 将范围小的条件放在前面。
10、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用 UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
11、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION和UNION ALL一样的道理。
12、使用in时，在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，这样可以减少判断的次数
13、 当用SELECT INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示声明语句，在另一个连接中 SELECT * from sysobjects可以看到 SELECT INTO 会锁住系统表， Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它！！！这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
14、 一般在GROUP BY和HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By和Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
15、一次更新多条记录比分多次更新每次一条快,就是说批处理好
16、慎用临时表，临时表存储于tempdb库中，操作临时表时，会引起跨库操作。尽量用结果集和表变量来代替它。
17、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过，并且被组织到一个执行规划里、且存储在数据库中的 SQL语句，是控制流语言的集合，速度当然快。
18、不要在一段SQL或者存储过程中多次使用相同的函数或相同的查询语句，这样比较浪费资源,建议将结果放在变量里再调用。这样更快。
19、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
1.有索引的列优先，都有索引的看查询出来的数据量，少的优先
in ,not in,<>,is null,is not null 等由于不会走索引，尽量不要使用。
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1K以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1K以下'
以 上两个SQL中dy_dj及xh_bz两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的 比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
2.选择最有效率的表名顺序
sql解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表
如果tab2中记录数明显高于tab1，用
SELECT COUNT(*) FROM tab2, tab1
效率明显优于
SELECT COUNT(*) FROM tab1, tab2
1、操作符号： NOT IN操作符
此 操作是强列推荐不使用的，因为它不能应用表的索引。推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替 "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", "LIKE '%500'"，因为他们不走索引全是表扫描。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作. 如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
2、注意union和union all的区别。union比union all多做了一步distinct操作。能用union all的情况下尽量不用union。
3、查询时尽量不要返回不需要的行、列。另外在多表连接查询时，尽量改成连接查询，少用子查询。
4、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用存储过程来代替它。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。
我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，
直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
5、创建合理的索引，对于插入或者修改比较频繁的表，尽量慎用索引。因为如果表中存在索引，插入和修改时也会引起全表扫描。
索引一般使用于where后经常用作条件的字段上。
6、在表中定义字段或者存储过程、函数中定义参数时，将参数的大小设置为合适即可，勿设置太大。这样开销很大。
7、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。
select * from chineseresume where title in ('男','女')
Select * from chineseresume where between '男' and '女'是一样的。由于in会在比较多次，所以有时会慢些。
8、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
9、WHERE后面的条件顺序影响
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以 上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，如果dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的 比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。所以尽量 将范围小的条件放在前面。
10、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用 UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
11、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION和UNION ALL一样的道理。
12、使用in时，在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，这样可以减少判断的次数
13、 当用SELECT INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示声明语句，在另一个连接中 SELECT * from sysobjects可以看到 SELECT INTO 会锁住系统表， Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它！！！这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
14、 一般在GROUP BY和HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By和Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
15、一次更新多条记录比分多次更新每次一条快,就是说批处理好
16、慎用临时表，临时表存储于tempdb库中，操作临时表时，会引起跨库操作。尽量用结果集和表变量来代替它。
17、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过，并且被组织到一个执行规划里、且存储在数据库中的 SQL语句，是控制流语言的集合，速度当然快。
18、不要在一段SQL或者存储过程中多次使用相同的函数或相同的查询语句，这样比较浪费资源,建议将结果放在变量里再调用。这样更快。
19、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
2011年8月8日 星期一
訂閱：
文章 (Atom)